تحديث 2024

لقد حققنا إنجازًا كبيرًا في المشروع بفضل تعاون المجتمع! أحد المساهمين، alphab0ing، كان يعمل على إنشاء ROM مخصص للوحة 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: صورة إقلاع أندرويد، kernel (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: بيانات نظام ملفات ext2 rev 1.0، UUID=b886e36e-ac40-5948-86dd-27c114bd225e، اسم الحجم "oem" (امتدادات) (ملفات كبيرة) (ملفات ضخمة)
		- system.img: بيانات نظام ملفات ext2 rev 1.0، UUID=0a7fc206-6c88-5018-bacd-4ea8a11db7ca (امتدادات) (ملفات كبيرة) (ملفات ضخمة)
		- trust.img: بيانات
		- uboot.img: بيانات
		- vbmeta.img: بيانات
		- vendor.img: بيانات نظام ملفات ext2 rev 1.0، UUID=67531afd-7aed-52f3-9196-b1cdad9fd724، اسم الحجم "vendor" (امتدادات) (ملفات كبيرة) (ملفات ضخمة)

تمت مشاركة ملفات تحديث OTA (HP-22_T56_EEA صورة نظام أندرويد 3.10 release-keys) على أرشيف الإنترنت.

بفضل هذه الملفات، تمكن alphab0ing من الحصول على DTS (مصدر شجرة الجهاز) الأصلي للجهاز (تحميل). هذا أمر حاسم لتطوير ROM مخصص ولتحسين فهم الأجهزة. دعونا نرى كيف يتقدم هذا!

وضع محمل Rockchip

يعمل معالج RK3399 على تشغيل أجهزة أندرويد. تأتي معالجات Rockchip مع “وضع المحمل” كميزة قياسية.

مجموعة الأدوات التي استخدمتها هي:

• Rockchip Driver Assistant v4.5 من ChinaGadgetsReviews
• rkDumper 1.09 test من هذا المنشور على XDA
• Android Tool Release v2.69 من ChinaGadgetsReviews

هناك إصدار أحدث من برنامج التشغيل متاح للتنزيل، ولكنه معروف بأنه غير متوافق مع rkDumper.

للعب بهذا، ستحتاج إلى تفكيك وحدة التحكم Bowflex، وفك الغطاء الخلفي البلاستيكي، وإعادة تجميعها في “شكل عاري”. لا تحاول هذا، لأن اللعب مع أجهزة أندرويد في وضع المحمل يمكن أن يؤدي إلى تلف دائم للجهاز.

إليك الأجزاء ذات الصلة من لوحة المنطق الخاصة بأندرويد لأشياء Rockchip:

يمكنك إبقاء تطبيق Android Tool Release مفتوحًا في جميع الأوقات كمرجع للتحقق من الوضع الذي تكون فيه وحدة التحكم.

عند تشغيل الجهاز في “الوضع العادي” وتوصيله بجهاز كمبيوتر، يتعرف عليه كـ NFTM-LAR:

NFTM-LAR:
  معرف المنتج: 0x0001
  معرف البائع: 0x2207 (Fuzhou Rockchip Electronics Co., Ltd.)
  الإصدار: 3.10
  السرعة: تصل إلى 480 ميجابت/ثانية
  الشركة المصنعة: Vanzo
  معرف الموقع: 0x14120000 / 9
  التيار المتاح حاليًا (mA): 500
  التيار المطلوب (mA): 500
  التيار التشغيلي الإضافي (mA): 0

عند إيقاف تشغيل الجهاز، وتوصيله عبر USB بجهاز كمبيوتر، والضغط على زر “الاسترداد” وتشغيله، يجب أن يتم التمهيد في “وضع المحمل”. سيصدر الجهاز “صفيرًا”، لكن الشاشة ستظل ثابتة. يمكنك إيقاف التشغيل، والانتظار دقيقة، وتشغيل الجهاز، وسيتم التمهيد بشكل طبيعي.

لا تتعامل أجهزة أندرويد مع “الصفير” بعد تشغيل الجهاز، ولكن من خلال لوحات PCBs الأخرى من Nautilus.

سيتم الآن الإبلاغ عن الجهاز إلى الكمبيوتر كـ USB download gadget (الرقم التسلسلي مخفي):

USB download gadget:
  معرف المنتج: 0x330c
  معرف البائع: 0x2207 (Fuzhou Rockchip Electronics Co., Ltd.)
  الإصدار: 99.99
  الرقم التسلسلي: XXXXXXXXXXXXXXX
  الشركة المصنعة: Rockchip
  معرف الموقع: 0x14120000

بعد تشغيل rkDumper ضد وحدة التحكم، نحصل على معلومات حول الأقسام:

تم العثور على علامة "EFI PART" (تفريغ RKFP FW)

تم حفظ القسم "EFI_part" (0x00004000) (التنسيق: تفريغ RockChip RKFP)
تم حفظ القسم "uboot_a" (0x00002000) (التنسيق: ملف صورة Rockchip uboot)
تم حفظ القسم "uboot_b" (0x00002000) (التنسيق: ملف صورة Rockchip uboot)
تم حفظ القسم "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، ولكن لا يبدو أنه من الممكن نسخها احتياطيًا نظرًا لعدم وجود أذونات الجذر:

> 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 وقراءتها خارجيًا لنسخ جميع محتوياتها احتياطيًا. سيكون ذلك جيدًا لإنشاء ROM مخصص، لكنني لن أفك لحام الشريحة من وحدة التحكم الوحيدة لدي (سيكون من الرائع أن يكون لدي واحدة احتياطية).