Progetto di ingegneria inversa. Iniziato con il tapis roulant Bowflex Treadmill 22, ma si è poi generalizzato per qualsiasi macchina con Android venduta da Nautilus Inc. (Nautilus, Bowflex, Schwinn).
Abbiamo raggiunto un traguardo importante nel progetto grazie alla collaborazione della comunità! Un collaboratore, alphab0ing, ha lavorato alla creazione di una ROM personalizzata per la scheda Vantron RK3399 di Bowflex. Puoi vedere di più in questo thread su GitHub.
È passato più di un anno da quando la mia console ha ricevuto un aggiornamento di sistema via OTA. Mi sono subito connesso via ADB per fare un backup dei file (se riuscivo a trovarli) e fortunatamente ci sono riuscito!
L’aggiornamento è stato memorizzato nella tipica directory di lavoro di Nautilus, /sdcard/Nautilus/redbend/
. I file estratti sono i seguenti:
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
Il file 1_delta.rdp
era particolarmente grande, quindi ho supposto che lì si trovasse la magia. Dopo aver ispezionato un po’ il file, sono arrivato a questo:
1_delta.rdp: Java archive data (JAR): Decomprimere come un .zip
- payload.bin: Estrarre 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)
I file dell’aggiornamento OTA (HP-22_T56_EEA Android OS Image 3.10 release-keys) sono stati condivisi su Internet Archive.
Con questi file, alphab0ing è riuscito a ottenere il DTS (Device Tree Source) originale del dispositivo (scarica). Questo è cruciale per lo sviluppo di ROM personalizzate e per comprendere meglio l’hardware. Vedremo come si evolve!
Un processore RK3399 alimenta l’hardware Android. I processori Rockchip sono dotati di una “loader mode” come caratteristica standard.
Il set di strumenti che ho utilizzato è:
C’è una versione più recente del driver disponibile per il download, ma è noto che è incompatibile con rkDumper.
Per giocare con questo, dovrai smontare la Console Bowflex, svitare il coperchio posteriore in plastica e rimontarla in una “forma nuda”. Non tentare questo, poiché giocare con l’hardware Android in Loader Mode può portare a un dispositivo permanentemente danneggiato.
Ecco le parti rilevanti della scheda logica Android per le cose di Rockchip:
Puoi tenere aperta l’applicazione Android Tool Release tutto il tempo come riferimento per verificare in quale modalità si trova la console.
Con la macchina accesa in “modalità normale” e collegata a un computer, viene identificata come NFTM-LAR
:
NFTM-LAR:
Product ID: 0x0001
Vendor ID: 0x2207 (Fuzhou Rockchip Electronics Co., Ltd.)
Version: 3.10
Velocità: Fino a 480 Mb/s
Produttore: Vanzo
ID Posizione: 0x14120000 / 9
Corrente Disponibile (mA): 500
Corrente Richiesta (mA): 500
Corrente Extra di Operazione (mA): 0
Con la macchina spenta, collegata tramite USB a un computer, tenendo premuto il “Recovery button” e accendendola, dovrebbe avviarsi in “Loader mode”. La macchina “suonerà”, ma lo schermo rimarrà statico. Puoi spegnere, aspettare un minuto, accendere e la macchina si avvierà normalmente.
L’hardware Android non gestisce il “suono” dopo l’accensione della macchina, ma attraverso le altre PCB di Nautilus.
Ora verrà riportato sul computer come USB download gadget
(Numero di Serie nascosto):
USB download gadget:
Product ID: 0x330c
Vendor ID: 0x2207 (Fuzhou Rockchip Electronics Co., Ltd.)
Versione: 99.99
Numero di Serie: XXXXXXXXXXXXXXX
Produttore: Rockchip
ID Posizione: 0x14120000
Dopo aver eseguito rkDumper contro la console, otteniamo informazioni sulle partizioni:
"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
e uboot_b
sono stati estratti con successo, ma tutte le altre partizioni contrassegnate come (formato: sconosciuto)
sono state mal salvate, estraendo solo valori esadecimali CC
da esse.
Un caso simile al mio è stato documentato su 4pda, e dopo aver chiesto allo sviluppatore di rkDumper, lui dice che deve esserci un nuovo loader di RockChip in atto. Seguire questo metodo sembra essere impraticabile per ora.
Alcuni dati simili possono essere trovati tramite adb, ma non sembra possibile fare un backup poiché mancano i permessi di 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
Qualcosa che possiamo fare è dissaldare il chip eMMC e leggerlo esternamente per poter fare un backup di tutto il suo contenuto. Sarebbe utile per creare una ROM personalizzata (Custom ROM), ma non dissalderei quello della mia UNICA Console (sarebbe bello averne una di riserva).
©2022-2024 Sebastián Barrenechea. Tutti i diritti riservati.
Costruito con Astro v4.16.13.