Обновление 2024

Мы достигли значительного этапа в проекте благодаря сотрудничеству сообщества! Один из участников, alphab0ing, работает над созданием кастомной прошивки для платы Bowflex Vantron RK3399. Подробнее можно узнать в этом обсуждении на GitHub.

Прошел уже более года с тех пор, как моя консоль получила обновление системы через OTA. Я быстро подключился через ADB, чтобы сделать резервную копию файлов (если смогу их найти), и, к счастью, мне это удалось!

Обновление было сохранено в типичном рабочем каталоге Nautilus, /sdcard/Nautilus/redbend/. Извлеченные файлы следующие:

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

Файл 1_delta.rdp был особенно большим, поэтому я предположил, что именно в нем содержится основная информация. После некоторого анализа файла я пришел к следующему:

1_delta.rdp: Данные архива Java (JAR): Распакуйте как .zip
	- payload.bin: Извлеките с помощью https://github.com/ssut/payload-dumper-go
		- boot.img: Android bootimg, ядро (0x10008000), ramdisk (0x11000000), второй этап (0x10f00000), размер страницы: 2048, cmdline (console=ttyFIQ0 androidboot.baseband=N/A androidboot.wificountrycode=US androidboot.veritymode=enforcing androidboot.hardware=r)
		- dtbo.img: данные
		- oem.img: Данные файловой системы Linux rev 1.0 ext2, UUID=b886e36e-ac40-5948-86dd-27c114bd225e, имя тома "oem" (extents) (большие файлы) (огромные файлы)
		- system.img: Данные файловой системы Linux rev 1.0 ext2, UUID=0a7fc206-6c88-5018-bacd-4ea8a11db7ca (extents) (большие файлы) (огромные файлы)
		- trust.img: данные
		- uboot.img: данные
		- vbmeta.img: данные
		- vendor.img: Данные файловой системы Linux rev 1.0 ext2, UUID=67531afd-7aed-52f3-9196-b1cdad9fd724, имя тома "vendor" (extents) (большие файлы) (огромные файлы)

Файлы обновления OTA (HP-22_T56_EEA Android OS Image 3.10 release-keys) были загружены на Internet Archive.

С этими файлами alphab0ing смог получить оригинальный DTS (Device Tree Source) устройства (скачать). Это важно для разработки кастомной прошивки и лучшего понимания аппаратного обеспечения. Посмотрим, как это будет развиваться!

Режим загрузчика Rockchip

Процессор RK3399 управляет аппаратным обеспечением Android. Процессоры Rockchip имеют стандартную функцию “режим загрузчика”.

Инструменты, которые я использовал:

• Rockchip Driver Assistant v4.5 с ChinaGadgetsReviews
• rkDumper 1.09 test с этого поста на XDA
• Android Tool Release v2.69 с ChinaGadgetsReviews

Существует более новая версия драйвера для загрузки, но известно, что она несовместима с rkDumper.

Чтобы поиграть с этим, вам нужно будет разобрать консоль Bowflex, открутить пластиковую заднюю крышку и собрать ее в “голом виде”. Не пытайтесь это сделать, так как игра с аппаратным обеспечением Android в режиме загрузчика может привести к постоянной поломке устройства.

Вот соответствующие части логической платы Android для работы с Rockchip:

Вы можете держать приложение Android Tool Release открытым все время как справочник для проверки, в каком режиме находится консоль.

Когда машина включена в “нормальном режиме” и подключена к компьютеру, она определяется как NFTM-LAR:

NFTM-LAR:
  Product ID: 0x0001
  Vendor ID: 0x2207 (Fuzhou Rockchip Electronics Co., Ltd.)
  Version: 3.10
  Скорость: до 480 Мбит/с
  Производитель: Vanzo
  Location ID: 0x14120000 / 9
  Текущий доступный ток (мА): 500
  Текущий требуемый ток (мА): 500
  Дополнительный рабочий ток (мА): 0

Когда машина выключена, подключена через USB к компьютеру, удерживая кнопку “Recovery” и включая ее, она должна загрузиться в “режим загрузчика”. Машина “пикнет”, но экран останется статичным. Вы можете выключить, подождать минуту, включить, и машина загрузится нормально.

Аппаратное обеспечение Android не обрабатывает “пик” после включения машины, но через другие платы Nautilus.

Теперь она будет сообщать компьютеру как USB download gadget (серийный номер скрыт):

USB download gadget:
  Product ID: 0x330c
  Vendor ID: 0x2207 (Fuzhou Rockchip Electronics Co., Ltd.)
  Version: 99.99
  Серийный номер: XXXXXXXXXXXXXXX
  Производитель: Rockchip
  Location ID: 0x14120000

После запуска rkDumper против консоли мы получаем информацию о разделах:

Найден знак "EFI PART" (дамп RKFP FW)

Раздел "EFI_part" (0x00004000) сохранен (формат: дамп RockChip RKFP)
Раздел "uboot_a" (0x00002000) сохранен (формат: образ uboot Rockchip)
Раздел "uboot_b" (0x00002000) сохранен (формат: образ uboot Rockchip)
Раздел "trust_a" (0x00002000) сохранен (формат: неизвестный)
Раздел "trust_b" (0x00002000) сохранен (формат: неизвестный)
Раздел "misc" (0x00002000) сохранен (формат: неизвестный)
Раздел "resource" (0x00008000) сохранен (формат: неизвестный)
Раздел "kernel" (0x00010000) сохранен (формат: неизвестный)
Раздел "dtb" (0x00002000) сохранен (формат: неизвестный)
Раздел "dtbo_a" (0x00002000) сохранен (формат: неизвестный)
Раздел "dtbo_b" (0x00002000) сохранен (формат: неизвестный)
Раздел "vbmeta_a" (0x00000800) сохранен (формат: неизвестный)
Раздел "vbmeta_b" (0x00000800) сохранен (формат: неизвестный)
Раздел "boot_a" (0x00020000) сохранен (формат: неизвестный)
Раздел "boot_b" (0x00020000) сохранен (формат: неизвестный)
Раздел "backup" (0x00038000) сохранен (формат: неизвестный)
Раздел "security" (0x00002000) сохранен (формат: неизвестный)
Раздел "cache" (0x00100000) сохранен (формат: неизвестный)
Раздел "system_a" (0x00500000) сохранен (формат: неизвестный)
Раздел "system_b" (0x00500000) сохранен (формат: неизвестный)
Раздел "metadata" (0x00008000) сохранен (формат: неизвестный)
Раздел "vendor_a" (0x00100000) сохранен (формат: неизвестный)
Раздел "vendor_b" (0x00100000) сохранен (формат: неизвестный)
Раздел "oem_a" (0x00100000) сохранен (формат: неизвестный)
Раздел "oem_b" (0x00100000) сохранен (формат: неизвестный)
Раздел "frp" (0x00000400) сохранен (формат: неизвестный)
Раздел "sw_release" (0x00ed7000) сохранен (формат: неизвестный)
Раздел "video" (0x0047e000) сохранен (формат: неизвестный)
Раздел "userdata" (0x0169bbdf) сохранен (формат: неизвестный)

uboot_a и uboot_b были успешно извлечены, но все остальные разделы, помеченные как (формат: неизвестный), плохо резервируются, извлекая из них только значения CC в шестнадцатеричном формате.

Случай, похожий на мой, был задокументирован на 4pda, и после вопроса разработчику rkDumper, он сказал, что, вероятно, используется новый загрузчик RockChip. Следование этому методу пока кажется неосуществимым.

ADB

Некоторые аналогичные данные можно найти через adb, но, похоже, их невозможно сохранить, так как у нас нет 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

Другие идеи

Одним из вариантов является выпаивание чипа eMMC и чтение его содержимого внешним образом для создания резервной копии всех данных. Это было бы полезно для создания кастомной прошивки, но я не буду выпаивать чип из своей ЕДИНСТВЕННОЙ консоли (было бы здорово иметь запасную).