BlackLotus-analysis-stage2-bootkit-rootkit-stage

تحليل BlackLotus للمرحلة الثانية من bootkit-rootkit

قبل أن نخوض في هذا الأمر الإلهي(صدقني إنه شيء إلهي لا يمكن لأحد أن يفعله بدون مشيئة الله(على الأقل هذا رأيي في هذا الأمر))، إليك هاش ملف bootkit

أول الأشياء أولاً، هكذا يبدو النظام السليم

``` C:\Windows\system32>BCDEdit

Windows Boot Manager

identifier {bootmgr} device partition=\Device\HarddiskVolume9 path \EFI\MICROSOFT\BOOT\BOOTMGFW.EFI description Windows Boot Manager locale en-US inherit {globalsettings} default {current} resumeobject {3f80ecd0-df10-11ed-bafc-80a84b2564bb} displayorder {current} toolsdisplayorder {memdiag} timeout 30

Windows Boot Loader

identifier {current} device partition=C: path \Windows\system32\winload.efi description Windows 10 locale en-US inherit {bootloadersettings} recoverysequence {3f80ecd2-df10-11ed-bafc-80a84b2564bb} displaymessageoverride Recovery recoveryenabled Yes isolatedcontext Yes allowedinmemorysettings 0x15000075 osdevice partition=C: systemroot \Windows resumeobject {3f80ecd0-df10-11ed-bafc-80a84b2564bb} nx OptIn bootmenupolicy Standard

الآن في تحليلي، لم أنجح أبدًا في إصابة جهازي، لذا سأستخدم المثال من منشور مدونة الباحث الآسيوي المُشار إليه سابقًا، وهذا هو الشكل الذي يفترض أن يبدو عليه الجهاز المُصاب```
    // Windows Boot Manager
    // --------------------
    // identifier              {9dea862c-5cdd-4e70-acc1-f32b344d4795}
    // description             Windows Boot Manager
    // locale                  en-US
    // inherit                 {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
    // bootdebug               Yes
    // displayorder            {57e1b615-0355-11ec-abb0-005056c00008}
    // timeout                 30

    // Windows Boot Loader
    // -------------------
    // identifier              {57e1b615-0355-11ec-abb0-005056c00008}
    // device                  boot
    // path                    \system32\hvloader.efi
    // description             Hoy la disco se flota
    // locale                  en-US
    // inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
    // truncatememory          0x10000000
    // avoidlowmemory          0x1000
    // nointegritychecks       Yes
    // testsigning             Yes
    // isolatedcontext         Yes
    // osdevice                boot
    // systemroot              \
    // ems                     Yes

=============================================================================

=============================================================================

قبل أن نبدأ، كيف يقوم المرء بإعداد البيئة لتحليل وحدة efi على أي حال؟ حسنًا، يعود الفضل إلى @MaverickMusic__ ، فقد أعطاني هذا الرابط أثناء نقاش معه( https://zhuanlan-zhihu-com.translate.goog/p/343293521?_x_tr_sl=auto&_x_tr_tl=en&_x_tr_hl=en-GB ). لم أتبع الخطوات هناك بالكامل، لذا إليك ما فعلته بالضبط ليكون لدينا بيئة جاهزة للعمل:

-أولاً قمت بتثبيت edk2(https://github.com/tianocore/tianocore.github.io/wiki/Windows-systems)

-ثانياً قمت بتكوين ovmf الخاص بي على وضع debug وليس release(سيساعدنا هذا لاحقاً). إليك الأمر build -a X64 -t VS2019 -b DEBUG -p OvmfPkg/OvmfPkgX64.dsc

-ثالثاً كان عليّ تكوين windbg الخاص بي. كيف بحق الجحيم فعلت هذا؟ قمت بتنزيل كل شيء من هذا الرابط(git clone https://github.com/microsoft/WinDbg-Samples). ثم قمت بتجميع ExdiGdbSrv.sln. ثم اتبعت كل شيء من هذا الرابط(https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-qemu-kernel-mode-debugging-using-exdi)، بدءاً من حيث ورد Use regsvr32 to register the DLL in an Administrator command prompt. وحتى PS>.\Start-ExdiDebugger.ps1 -ExdiTarget "QEMU" -GdbPort 1234 -Architecture x64 -ExdiDropPath "C:\path\to\built\exdi\files". أعلم أنه مُحيّر، لكن أرجو الانتظار بصبر لأنني سأقوم بالتأكيد بتسجيل فيديو سأشرح فيه كل خطوة! رائع، إذن الآن بعد أن أصبح لدينا بيئة جاهزة لتصحيح الأخطاء، كيف بحق الجحيم نقوم بتصحيح الكود؟ نبدأ بتشغيل qemu، وفي حالتي قمت بذلك من خلال تنفيذ qemu-system-x86_64.exe -L . -bios OVMF.fd -hdd dos.img -debugcon file:debug.log -global isa-debugcon.iobase=0x402 . بمجرد تشغيل أمر qemu ذهبت فوراً واخترت compat_monitor0 من قائمة view في qemu. يجب أن يبدو هكذا عندما تفعل ذلك.

أيضاً بعد تحديد هذا يجب عليك إدخال gdbserver لبدء نسخة بعيدة من تصحيح أخطاء gdb والتي سنتصل بها مع windbg باستخدام هذا الأمر .\Start-ExdiDebugger.ps1 -ExdiTarget "QEMU" -GdbPort 1234 -Architecture x64. رائع، بمجرد اتصالنا بها سيبدو هكذا

``` So how do we set up a breakpoint in order to debug the bootkit? Well that's we we compiled the ovmf image as debug rather than release. If you specifically start qemu with that command you'll have qemu run and debug messages will be logged in a file called debug.log , which looks like this ```

رائع! الآن لفهم هذه المخرجات، السطر الوحيد المهم في حالتنا هو EntryPoint=0x000062C9A8C وهو عنوان التحميل المفضَّل عندما نقوم بتشغيل أداة الإقلاع bootkit. تحديدًا بالنسبة لـ bootkit، يتراوح بين 0x62C4A8C أو 0x62C9A8C. الآن يمكننا إعادة تموضع البرنامج في IDA والقيام بعملنا المعتاد :) . استمتع ببقية المدونة!

=============================================================================

مقارنة BinDiff بين winload.efi الأصلي والملف الذي ألقاه BlackLotus