دسترسی به داخل emmc با چیپ کوالکام& پشت پرده 9008

نویسنده: محمد دانه زن

بازدید: 1842 نفر

به روز رسانی: 1400/12/10

در 1,2,3,4,5, قسمت این مقاله گانجانیده شده است

بخش اول

همه دسترسی ها منوط به داشتن دسترسی 9008 یا Emergency Download Mode (EDL) h است که با زدن تست پوینت مخصوص هر گوشی امکان پذیر است. اصلی ترین بوت-مد (boot-mode) دستگاه های با چیپ کوالکام (Primary Bootloader) است.

برای استفاده از این حالت، کاربران باید فایل پروگرامر یا (programmer files)  دارای امضای OEM را در اختیار داشته باشند که به نظر می‌رسد برای دستگاه‌های مختلفی از این دست در دسترس عموم هستند.

نکته مهم : اینجا پروگرامر, باکس پروگرامر نیست یک فایل است و برای هر CPU  فرق دارد . مثلا

بوت امن در چیپ های کوالکام

یه حالت کلی در این تصویر زیر به نمایش خواهیم گذاشت که ذهنیت شمارا تغییر دهد:

emmc  آدرس شروع بوت-لودر اصلی رو در خودش داره که بعد از زدن دکمه پاور شریع به اجرا میشود که بوت نرمال یا حالت آماده به کار گوشی رو هدیه میکند اما اول  زودی SBL با امضای دیجیتال را در حافظه داخلی (imem) بارگیری می کند و صحت آن را تأیید می کند.

این تایید صحت مرحله بسیار مهمی است .

همه PBL های استخراج شده ما 32 بیتی بودند (در aarch32 اجرا می شدند)، که در آن SBL ها یا aarch32 یا aarch64 بودند که در آن PBL مسئول انتقال است.

برخی از دستگاه ها به جای SBL دارای XBL (بوت لودر قابل توسعه) هستند. SBL, DDR را مقداردهی اولیه می کند و img دارای امضای دیجیتالی مانند ABOOT (که رابط fastboot را پیاده سازی می کند) و TrustZone بارگیری می کند و دوباره صحت آنها را تأیید می کند. گواهینامه های امضا شده دارای گواهی ریشه هستند که در سخت افزار مستقر شده اند.

سپس ABOOT صحت بوت یا recovery را تأیید می کند، “”هسته لینوکس و initramfs را از بوت یا تصاویر بازیابی بارگیری می کند. initramfs یک آرشیو cpio (gzipped) است که در هنگام شروع اولیه هسته لینوکس در rootfs (یک سیستم فایل RAM نصب شده در “/” یعنی ریشه فایل لینوکس) بارگذاری می شود. این شامل باینری init، اولین فرآیند فضای کاربر است. ABOOT خط فرمان هسته و پارامترهای initramfs را برای هسته لینوکس در “Device Tree Blob (DTB)”آماده می کند و سپس “اجرا” (اشاره گر خط اجرا) را به هسته اندروید (لینوکس) منتقل می کند.””

“” یک نکته خیلی تخصصی است که در فرآیند راه اندازی لینوکس و دستکاری هسته لینوکس به درد میخورد 

واین توصیحات درمورد راه اندازی نرمال گوشی است اما اگر تست پونت بزنیم به گوشی چطور میاد بالا از لحاظ علمی باز هم مثل بالا برسی میکنیم

در این حالت، دستگاه از طریق USB خود را به عنوان Qualcomm HS-USB 9008 معرفی می کند. EDL توسط PBL فراخوانی  می شود. از آنجایی که PBL مقیم ROM است، EDL نمی تواند توسط نرم افزار خراب شود(به نوعی فقط خواندنی میشود) حالت EDL خود پروتکل *Qualcomm Sahara را پیاده‌سازی می‌کند، که یک پروگرامر(firehose) با امضای دیجیتالی OEM (یک باینری ELF در دستگاه‌های اخیر، MBN در دستگاه‌های قدیمی‌تر) را از طریق USB، آپلود میکند روی گوشی و یک ترمینال برای اهداف ما میشود.

*یک پروتکل است

که همه این ها داخل یک img به نام pbl  انجام میشود که به صورت کد هست که با زبان ++C توسعه داده شده

PBL(Primary Bootloader)

برای تأیید دانش مبتنی بر تجربی خود،  قبل از آن، ما برخی از تجزیه و تحلیل اولیه  در چیپ PBL ;MSM8937/MSM8917 مربوط به چیپ های مذبور انجام دادیم تا طرح آن را در یک دیدگاه سطح بالا درک کنیم. ما معتقدیم PBL های دیگر آنقدرها متفاوت نیستند. (شبه به هم هستند)

کنترل کننده بازنشانی (آدرس 0x100094) PBL تقریباً به صورت زیر است .

(برخی از کدهای شبه برای خوانایی حذف شده اند)

یک شبه کد داریم فقط برای ارضای حس کنجکاوی شما عزیزان است:

int init()
{
  int (__fastcall *v5)(pbl_struct *); // r1
  __mcr(15, 0, 0x100000u, 12, 0, 0);
  if ( !(MEMORY[0x1940000] & 1) )
  {
    if ( !reset_MMU_and_other_stuff() )
      infinite_loop();
    memzero_some_address();
    timer_memory_stuff();
    init_pbl_struct();
    v4 = 0;
    while ( 1 )
    {
      v5 = *(&initVector + v4);
      if ( v5 )
        v3 = v5(&pbl);
      if ( v3 )
        pbl_error_handler("./apps/pbl_mc.c", 516, 66304, v3);
      if ( ++v4 >= 0x14 )
      {
        while (1);
      }
    }
  }
}

توضیح برای این کد نیازی نیست مافقط قصد تداعی بهتر این پروسه را در ذهن شما را داریم

فراخوانی پروسیجر یا img , بوت لودر ثانویه  توسط PBL و مرور حالت کلی که گفتیم به صورت شبه کد برای حالت edl:

int __fastcall pbl_sense_jtag_test_points_edl(pbl_struct *pbl)
{
[...]
  pbl->bootmode_reason = bootmode_reason_0;
  if ( !(MEMORY[0xA601C] & 8) )                 // jtag fuse
  {
    if ( MEMORY[0xA606C] & 0x8000 )             // check test points
    {
      pbl->bootmode = edl;
      pbl->bootmode_reason = tp;
      return 0;
    }
    v4 = MEMORY[0x193D100];
    v5 = MEMORY[0x193D100] & 0xF;
    switch ( v5 )
    {
      case 1:
        v6 = bootmode_reason_2;
        pbl->bootmode = edl;
        break;
      case 2:
        pbl->bootmode = bootmode_80;
        pbl->bootmode_reason = bootmode_reason_3;
        goto LABEL_17;
      case 3:
        pbl->bootmode = bootmode_81;
        v6 = bootmode_reason_4;
        break;
      default:
        goto LABEL_17;
    }
    pbl->bootmode_reason = v6;
LABEL_17:
    MEMORY[0x193D100] = v4 & 0xFFF0;
    if ( pbl->bootmode_reason )
      return 0;
  }
  v2 = (MEMORY[0xA602C] >> 1) & 7;
  if ( v2 >= 8 )
    pbl_error_handler("./apps/pbl_hw_init.c", 227, 262656, ((MEMORY[0xA602C] >> 1) & 7));
  pbl->bootmode = v2;
  return 0;
}

پرایمری بوت_لودر تا این حد کافی است.

داخل firehose  چه میگذرد؟

دروافع یک ترمینال یا به عنوان دروازه عمل میکند بین کامپیوتر و گوشی که از طریف usb  تمامی فرمان هایی راکه دوست داریم اجرا میکنیم مثلا حذف Mi Account  یا FRP  یا IMEI .

همانطور که در بالا ذکر شد،پروگرام های edl , پروتکل Qualcomm Firehose را پیاده سازی می کنند. تجزیه و و دستورات از طریق XML (از طریق USB) منتقل می شوند. برای مثال، XML زیر باعث می‌شود که برنامه‌نویس یک img بوت‌لودر ثانویه (SBL) جدید (که از طریق USB نیز منتقل می‌شود) فلش کند .

اینطوری هست xml:

<?xml version="1.0" ?>
<data>
  <program SECTOR_SIZE_IN_BYTES="512" file_sector_offset="0" filename="sbl1.bin"
           label="sbl1" num_partition_sectors="1024" physical_partition_number="0" 
           size_in_KB="512.0" sparse="false" 
           start_byte_hex="0xc082000" start_sector="394256"/>
</data>
                                                                                 
                  

همانطور که مشاهده می شود، تگ مربوطه که به پروگرامر دستور می دهد یک img  جدید را فلش کند.

بررسی کد پروگرامر (پروگرامر Xiaomi Note 5A uglite aarch32 در این مورد) نشان می دهد که در واقع یک نوع SBL توسعه یافته است. روال اصلی آن به شرح زیر است:

int __cdecl SBLMain(pbl2sbl_struct *pbl2sbl_data)
{
  sbl_struct *vSbl; // r6
  
  [...]
  SBLStart(&off_805C070, vSbl);
  sub_801D0B0(off_805C078);
  sub_8040A2C(vSbl);
  initSBLStruct(&sblStruct, &unk_80678A0);
  sub_80408F4(&sblStruct);
  [...]
  return callImageLoad(&sblStruct, 0x15, imageLoad);
}

pbl2sbl_data داده‌ای است که از PBL به SBL در انتهای تابع pbl_jmp_to_sbl منتقل می‌شود. sbl داده های متنی SBL را حفظ می کند، جایی که اولین فیلد آن به یک کپی از pbl2sbl_data اشاره می کند.

ImageLoad تابعی است که وظیفه بارگیری بوت لودرهای بعدی از جمله ABOOT را بر عهده دارد:

[…] حذف شده ها هستند

int __fastcall ImageLoad(sbl_struct *sbl, image_load_struct *aImageLoad)
{
  [...]
  loop_callbacks(sbl, aImageLoad->callbacks);
  [...]
  if ( imageLoad->field_14 == 1 )
  {
    v5 = sub_801CCDC();
    uartB("Image Load, Start");
    v8 = imageLoad->field_C;
    if ( v8 == 1 )
    {
      if ( !boot_pbl_is_flash() )
      {
        [...]
        ERROR("sbl1_sahara.c", 816, 0x1000064);
        while ( 1 )
          ;
      }
	[...]
	  boot_elf_loader(v9, &v27);
	[...] 
  loop_callbacks(sbl, imageLoad->callbacks2);
	[...]
  return result;
}

تابع  ImageLoad با فراخوانی (با استفاده از روال loop_callbacks) یک سری توابع اولیه آغاز می شود:

LOAD:0805C0C8 callbacks  DCD nullsub_35+1
LOAD:0805C0CC            DCD boot_flash_init+1
LOAD:0805C0D0            DCD sub_801ACB0+1
LOAD:0805C0D4            DCD sub_804031C+1
LOAD:0805C0D8            DCD sub_803FF08+1
LOAD:0805C0DC            DCD sub_803FCD0+1
LOAD:0805C0E0            DCD firehose_main+1
LOAD:0805C0E4            DCD sub_8040954+1
LOAD:0805C0E8            DCD clock_init_start+1
LOAD:0805C0EC            DCD sub_801B1AC+1
LOAD:0805C0F0            DCD boot_dload+1

firehose main در نهایت در حلقه اصلی firehose قرار می گیرد و هرگز باز نمی گردد. جالب اینجاست که در SBL واقعی uglite، این سری از فراخوانی اولیه به صورت زیر است:

LOAD:0805B0C8 callbacks       DCD nullsub_36+1       
LOAD:0805B0CC                 DCD boot_flash_init+1
LOAD:0805B0D0                 DCD sub_8018E8C+1
LOAD:0805B0D4                 DCD sub_8039C80+1
LOAD:0805B0D8                 DCD sub_803986C+1
LOAD:0805B0DC                 DCD sub_8039634+1  
LOAD:0805B0E0                 DCD nullsub_37+1
LOAD:0805B0E4                 DCD sub_803A2B8+1
LOAD:0805B0E8                 DCD clock_init_start+1
LOAD:0805B0EC                 DCD sub_8019388+1
LOAD:0805B0F0                 DCD boot_dload+1

بنابراین، آنها فقط در پاسخ به تماس Firehose_main تفاوت دارند!

واینطوری میشود firehose میشیند روی گوشی و به عنوان ترمینال عمل میکند و ساختار داخلی نیز با زیان c/c++ ساخته شده است. است که باز هم بنویسم میتونیم فقط شبه کد بنویسیم

درقسمت دوم با ماهمراه باشید