BlackLotus-analysis-stage2-bootkit-rootkit-stage

BlackLotus स्टेज 2 बूटकिट-रूटकिट विश्लेषण

इस दिव्य चीज़ में गोता लगाने से पहले (मेरा विश्वास करें, यह कुछ दिव्य चीज़ है क्योंकि ईश्वर की इच्छा के बिना कोई भी यह नहीं कर सकता (कम से कम इस पर मेरी यही राय है)), यहाँ बूटकिट फ़ाइल का हैश है

सबसे पहले, एक स्वस्थ प्रणाली इस तरह दिखती है

``` 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 कमांड चलाया, मैंने तुरंत qemu के व्यू मेनू से compat_monitor0 चुना। ऐसा करने पर यह ऐसा दिखना चाहिए।

इसके अलावा, इसे चुनने के बाद आपको 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 है, जो बूटकिट चलाने पर पसंदीदा लोडेड पता है। विशेष रूप से इस बूटकिट के लिए यह 0x62C4A8C or 0x62C9A8C के बीच बदलता है। अब हम ida में प्रोग्राम को रीबेस कर सकते हैं और अपना सामान्य काम कर सकते हैं :)। ब्लॉग के बाकी हिस्से का आनंद लें!

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

मूल winload.efi और blacklotus द्वारा छोड़ी गई winload.efi के बीच Bindiffing