Z2A-BlackLotus चैलेंज स्टेज 2 बूटकिट-रूटकिट विश्लेषण
BlackLotus स्टेज 2 बूटकिट-रूटकिट विश्लेषण
इस दिव्य चीज़ में गोता लगाने से पहले (मेरा विश्वास करें, यह कुछ दिव्य चीज़ है क्योंकि ईश्वर की इच्छा के बिना कोई भी यह नहीं कर सकता (कम से कम इस पर मेरी यही राय है)), यहाँ बूटकिट फ़ाइल का हैश है
सबसे पहले, एक स्वस्थ प्रणाली इस तरह दिखती है
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
``` 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 ```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 बढ़िया तो एक बार हम कनेक्ट कर लेंगे तो यह ऐसा दिखेगा
तो बहुत बढ़िया, अब इस आउटपुट को समझने के लिए, हमारे मामले में एकमात्र प्रासंगिक पंक्ति EntryPoint=0x000062C9A8C है, जो बूटकिट चलाने पर पसंदीदा लोडेड पता है। विशेष रूप से इस बूटकिट के लिए यह 0x62C4A8C or 0x62C9A8C के बीच बदलता है। अब हम ida में प्रोग्राम को रीबेस कर सकते हैं और अपना सामान्य काम कर सकते हैं :)। ब्लॉग के बाकी हिस्से का आनंद लें!
=============================================================================
मूल winload.efi और blacklotus द्वारा छोड़ी गई winload.efi के बीच Bindiffing
हमें कुछ समानताएँ दिखती हैं लेकिन कुछ अंतर भी हैं, पर कुछ उपयोगी नहीं, वैसे भी....
=============================================================================
बढ़िया, तो चलिए पार्टी शुरू करते हैं।
बढ़िया, तो चलिए विश्लेषण शुरू करें। तो सबसे पहले हम देखते हैं कि हमारे पास एक function है जो कॉल होता है। अच्छा, तो इसका क्या है? खैर
अच्छा, एक और function। बिल्कुल नहीं... कुछ परिचित दिख रहा है?
अभी तक कुछ नहीं???
कोई बात नहीं, शायद अब
वही demangle function! अरे, पुराने दोस्त, नमस्ते :)))
अच्छा, लेकिन return (*(a1 + 88))(v2, &unk_62CEABC, 3i64); का क्या? सच में, केवल स्टैटिक दृष्टिकोण से मुझे नहीं पता कि क्या कहूँ, तो चलिए इसे समझने के लिए डिबगर का उपयोग करने की कोशिश करते हैं :))
तो जब हम स्ट्रिंग को demangle करते हैं, हमें मिलता है
तो अगला, जब हम कॉल instruction पर पहुँचते हैं
और हमें कोई जानकारी नहीं मिलती.... बढ़िया, लेकिन ऐसा क्यों? क्योंकि हमारे पास .pdb फ़ाइल नहीं है जिससे हम डिबग प्रतीक प्राप्त कर सकें.... अच्छा, कम से कम ida यहाँ मददगार है। तो हम जानते हैं कि "grand" function इनपुट के रूप में SystemTable->RuntimeServices लेता है, जो EFI_SYSTEM_TABLE प्रकार का है। अच्छा, अगर हम इसका निरीक्षण करें तो यह A pointer to the EFI Runtime Services Table. है। अगर हम गूगल पर खोजें तो हमें बहुत सारे दस्तावेज़ मिलते हैं, लेकिन एक महत्वपूर्ण दस्तावेज़ जो हमें मिलता है वह है https://uefi.org/sites/default/files/resources/UEFI\_Spec\_2\_1\_D.pdf । वहाँ कहा गया है
अच्छा, तो बहुत सारे पॉइंटर्स वाला एक struct, हाँ, लेकिन चलिए और ज़ूम इन करते हैं।
तो सबसे पहले यह VbsPolicyDisable को demangle करता है, अगर हम गूगल पर खोजें तो हमें ESET विश्लेषण मिलता है जो कहता है that this variable is evaluated by the Windows OS loader during boot and if defined, the core VBS features, such as HVCI and Credential Guard will not be initialized. , तो मूल रूप से यह वेरिएबल बूट स्तर पर वर्तमान "सुरक्षा" के लिए ज़िम्मेदार है। अच्छा, अगला हमारे पास वह function है जो उस वेरिएबल को लेता है और
और इसलिए हम इस निष्कर्ष पर पहुँच सकते हैं कि यह एक ऐसा function होना चाहिए जो किसी तरह उस वेरिएबल की स्थिति को बदलता है। अच्छा, तो कुछ संभावित function कौन से हो सकते हैं जो ऐसा कर सकते हैं? EFI_SYSTEM_TABLE में केवल एक ही ऐसा function है जो EFI_SET_VARIABLE SetVariable है;
तो हम निष्कर्ष निकालते हैं कि यह function बस VbsPolicyDisable को लेता है और उसे सेट करता है``` db 77h ; w .data:0000000180005034 db 59h ; Y .data:0000000180005035 db 3 .data:0000000180005036 db 32h ; 2 .data:0000000180005037 db 4Dh ; M .data:0000000180005038 db 0BDh ; ½ .data:0000000180005039 db 60h ; ` .data:000000018000503A db 28h ; ( .data:000000018000503B db 0F4h ; ô .data:000000018000503C db 0E7h ; ç .data:000000018000503D db 8Fh .data:000000018000503E db 78h ; x .data:000000018000503F db 4Bh ; K.
अब क्या इन बाइट्स में कुछ महत्वपूर्ण है? हाँ, यदि आपने संयोगवश blacklotus विश्लेषण का पहला भाग पढ़ा होगा तो आप जानते होंगे कि मैंने एक एशियाई शोधकर्ता के काम का संदर्भ दिया था। उस शोधकर्ता ने कृपया ड्रॉप किए गए bootkit का भी विश्लेषण किया। कृपया इसे देखें (https://www.cnblogs.com/DirWang/p/17294545.html#autoid-3-2-1), उनके विश्लेषण में उन्होंने हमें वह जानकारी दी। वे हमें https://github.com/Mattiwatti/EfiGuard/blob/master/EfiGuardDxe/PatchWinload.c की ओर इंगित करते हैं। वहाँ हमें एक समान पंक्ति दिखती है
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/33c755aa460f5bdc338c75f3f5e1322c731123299d59c43dcdf2be3b72d1276c.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/144b057568871a60a32e477ed1ae7e8d7090778a67b7fc24222f0f58fe44afc1.png" alt=""><figcaption></figcaption></figure>
</div>
क्या इसके पीछे कोई विशेष कारण है? सच कहूँ तो मुझे नहीं पता, यह मेरा पहली बार bootkit का विश्लेषण करना है। अगर आपके पास इस क्षेत्र में मुझसे अधिक अनुभव है तो कृपया मुझे बताएं या इस दस्तावेज़ को संपादित करने के लिए pr/pull request करें :)
\=============================================================================
बढ़िया, अगला, किस्मत हमारा साथ देती है और ida का स्यूडो कोड असेंब्ली के समान है
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/7457c9d8beb807556618728c7aba102109a472ef2f990f35ec344038fafc4cd5.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/e11c4b4e4260f7a91e6dc08bcabb7c3ac420dcee346b1bf9dff02835342f7837.png" alt=""><figcaption></figcaption></figure>
</div>
तो मुझे लगता है कि यहाँ EFI\_SYSTEM\_TABLE का सामान्य आरंभीकरण (initialisation) होता है, जो मूल रूप से यह तय करता है कि बूट प्रक्रिया को आगे कौन सी प्रक्रिया जारी रखेगी। और फिर हमारे पास PatchBootManager फ़ंक्शन कॉल है
\=============================================================================
PatchBootManager
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/66c49bf5b64655af7e0edfe384ad715912c02fbeea1ac1313e4f65479ab58f80.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/7a1dc3ac7c01cbd4cfd9b3ec614c357895210e4f03ae5d58000e6b047f84eb96.png" alt=""><figcaption></figcaption></figure>
</div>
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/3fc22a51052c24c9e436ace83a1672ce88bf25fb11103b32d0143fa0ab4d7216.png" alt="2">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/22c7869b067f26c6469e4baffcd4226535c47e82d4baaf7fa8e27820915b1580.png" alt=""><figcaption></figcaption></figure>
</div>
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/38cf7697523141faa68a59b52abd2a1ca14d0d9053f1e6960052a5093e3a94bb.png" alt="3">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/505a3fd02b96bcb823bf108ee03a8a1204827852260c1e8ce3902638237259b3.png" alt=""><figcaption></figcaption></figure>
</div>
और स्यूडो कोड से
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/9c8482f0faa4d4de5f8643acc4276ebbbfc57386e9b00a4057793b5c67b1bf3b.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/c44de61b9f089fd8972bcc8567110bc2d58c21e5465a7b4f14fc7beaefee30a3.png" alt=""><figcaption></figcaption></figure>
</div>
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/6809c28e881b3626d73a476cd31631891539f6a7b71cf276619f9cd2244d83e9.png" alt="2">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/c8cd4870cd0488e57cde3448ba01fdd44063f266516d8530731f42e6ccc5be78.png" alt=""><figcaption></figcaption></figure>
</div>
ठीक है, तो पहला फ़ंक्शन कॉल जो हम देखते हैं वह HandleProtocol है। तो यह कोड क्या करता है? सौभाग्य से, त्वरित Google खोज करने पर हमें यह मिल जाता है (https://tianocore-docs.github.io/edk2-ModuleWriteGuide/draft/5\_uefi\_drivers/54\_communication\_between\_uefi\_drivers.html) और हम देखते हैं कि यह `retrieve protocols` (प्रोटोकॉल पुनर्प्राप्त) करता है। बढ़िया, कुछ खास समझ नहीं आया। हाँ, मैं समझ गया दोस्तों। तो मूल रूप से यह अन्य UEFI ड्राइवरों द्वारा उपयोग की जाने वाली संचार सूचना विधियों को पुनर्प्राप्त करता है। बढ़िया, थोड़ी और खुदाई करते हैं। हम देखते हैं कि दूसरा पैरामीटर है
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/703c3f52bd8c3d10eaf046fc801cbc60ca7a62e9162d67a6ba63caf4c9e9038d.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/9d41aacaed9c15391beb8b1b62739572bf7f873508938ade770610eec371a17c.png" alt=""><figcaption></figcaption></figure>
</div>
यदि हम उन विशिष्ट बाइट्स की खोज करें तो हमें यह मिलता है
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/f4a8ed3b81486c8481c0f8894175f9d7390ddf62f9974ba025aad9827dea119e.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/882b5116cfd08886c3dac510443fb77c9aa31781eb234208ec81fdf313544c29.png" alt=""><figcaption></figcaption></figure>
</div>
तो EFI\_LOADED\_IMAGE\_PROTOCOL\_GUID आखिर करता क्या है? (https://uefi.org/specs/UEFI/2.10/09\_Protocols\_EFI\_Loaded\_Image.html) से उद्धरण: `किसी भी इमेज हैंडल पर लोड की गई इमेज के बारे में जानकारी प्राप्त करने के लिए उपयोग किया जा सकता है।`, किस प्रकार की जानकारी? ```यह अनुभाग EFI\_LOADED\_IMAGE\_PROTOCOL और EFI\_LOADED\_IMAGE\_DEVICE\_PATH\_PROTOCOL को परिभाषित करता है। क्रमशः, ये प्रोटोकॉल उस इमेज का वर्णन करते हैं जिसे मेमोरी में लोड किया गया है और उस डिवाइस पथ को निर्दिष्ट करते हैं जिसका उपयोग PE/COFF इमेज को EFI Boot Service LoadImage() के माध्यम से लोड करते समय किया गया था। इन विवरणों में वह स्रोत शामिल है जिससे इमेज लोड की गई थी, मेमोरी में इमेज का वर्तमान स्थान, इमेज के लिए आवंटित मेमोरी का प्रकार, और इमेज को आमंत्रित करते समय पारित किए गए पैरामीटर शामिल हैं।```
तो हमारे मामले में यह bootkit के बारे में जानकारी लेता है। अब एक समस्या है - हम फ़ंक्शन के परिणाम की वास्तव में जाँच नहीं कर सकते क्योंकि हमारे पास डीबग प्रतीक (debug symbols) नहीं हैं :/ लेकिन हम अनुमान लगा सकते हैं। और मैं यह अनुमान लगाता हूँ कि संरचना (पिछले फ़ंक्शन कॉल का परिणाम) rbx में होगी।
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/b8f744ecd9fd4be572a1e2d191b06231559eca2b32aeaa981a399eec7f3ee710.png" alt=""><figcaption></figcaption></figure>
अगला, हम डिमैंगल स्ट्रिंग (demangle string) को कॉल करते हैं
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/1fdc75d2dc9221250e6d46692770ad5240f7a0d6cda9cc5634749b327fc8c146.png" alt=""><figcaption></figcaption></figure>
जिससे हमें यह मिलता है
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/e073b265ff13675b755ec8413554bec74ab4eae57dd002b25694632eb43cbc8e.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/3654bb54071386cd020c43ed4a35fae40aec386897a0ca26a27b58b8e1a91c95.png" alt=""><figcaption></figcaption></figure>
</div>
और फिर हम कॉल करते हैं
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/c433aa63cddd2ecfb5ce0fd57a6774ad35b1c1ed4ee71e7cecb566cc861d2b80.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/6834be566cdd81f2410ec7d4ee97936d14a27017a723371eea3046b8590609f4.png" alt=""><figcaption></figcaption></figure>
</div>
\=============================================================================
sub\_180002B14
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/483f2b789c0fa6fe9378ba324f8e349bc72cbb45e540bbc2355ef55acaf1b6b4.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/d84d79115facbc0f9ff7afe06d70a18555e7d94bc196f6f9d0ff6b5cfd40408a.png" alt=""><figcaption></figcaption></figure>
</div>
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/19e2366fddab99fa3aa4375b8306475ee31d3bf9a3c3737efeeb4d627868404e.png" alt="2">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/6c808c76821c756eca776cf6290482f6f9829167f539bf31b2ad82b3de0af829.png" alt=""><figcaption></figcaption></figure>
</div>
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/ad0d06238e39e4ba1decb2f1305510a8375822b13ae9148d91e267d14762eb3b.png" alt="3">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/0e45e9ae64c3fbd8a61ffdf60ec2e532529d8cab6cfc7786fa2c91824233d347.png" alt=""><figcaption></figcaption></figure>
</div>
और स्यूडो कोड
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/c14b1eacbe8eef4155c4148b66fa95f93bbd9e6fc81e5ca80f1ddc5b2b9a7a16.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/b7c452865661d95b79886a48a455eba663c2e3915e0a81ad16dc7ddd8c2c0189.png" alt=""><figcaption></figcaption></figure>
</div>
बढ़िया, तो if तक सब कुछ स्वयं-व्याख्यात्मक है, अब if के बारे में क्या? हम फिर देखते हैं कि यह unk\_180005010 को पैरामीटर के रूप में लेकर एक कॉल करता है, जो फिर से बाइट्स की एक सरणी (array) है, आगे निरीक्षण करने पर यह ऐसा दिखता है
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/c3bb66f35a4e559ae793ba590fc0c342bdde1e1c9765e144cb450a809009655d.png" alt=""><figcaption></figcaption></figure>
अब यदि हम पहले बाइट्स का फिर से निरीक्षण करें और त्वरित खोज करें तो हमें यह मिलता है (https://github.com/theopolis/uefi-firmware-parser/blob/master/uefi\_firmware/guids/efiguids\_ami.py), और अधिक सटीक रूप से यह `'EFI_DEVICE_PATH_PROTOCOL_GUID': [0x09576e91, 0x6d3f, 0x11d2, 0x8e, 0x39, 0x00, 0xa0, 0xc9, 0x69, 0x72, 0x3b]`।
यदि हम फिर से uefi के स्पेक पेज पर जाएँ तो हम देखते हैं कि `किसी भी डिवाइस हैंडल पर भौतिक डिवाइस या लॉजिकल डिवाइस के बारे में सामान्य पथ/स्थान जानकारी प्राप्त करने के लिए उपयोग किया जा सकता है।` इसके अलावा हम यह भी देखते हैं `डिवाइस पथ उस डिवाइस का स्थान बताता है जिसके लिए हैंडल है`। ठीक है, और यदि हम थोड़ा स्क्रॉल करें तो हमें \_EFI\_DEVICE\_PATH\_PROTOCOL नामक एक फ़ंक्शन दिखता है। ठीक है, तो निष्कर्ष रूप में हम जानते हैं कि इसका संबंध EFI\_DEVICE\_PATH\_PROTOCOL\_GUID से है, लेकिन हमारा फ़ंक्शन EFI\_BOOT\_SERVICES प्रकार का है। तो क्या EFI\_BOOT\_SERVICES में कोई ऐसा फ़ंक्शन है जो प्रोटोकॉल को संभालने जैसा कुछ कर सकता है? हाँ, है। यदि हम https://www.intel.com/content/dam/doc/product-specification/efi-v1-10-specification.pdf की धारा 4.4 का निरीक्षण करें तो हम देखते हैं
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/918a0a5184849cbb87454df44c5ffa5e5fa586f223213287f6c7fbe737a0fbc8.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/fab94604327fe596d9eeb68368efcf0afc721ef7bfcdc07a8977392b4309238c.png" alt=""><figcaption></figcaption></figure>
</div>
अधिक सटीक रूप से, इसमें एक फ़ंक्शन है जिससे हम परिचित हैं (HandleProtocol)। बढ़िया
अगला, हम एक और फ़ंक्शन कॉल देखते हैं, इस बार हमारे लिए अज्ञात। देखते हैं यह कौन से तर्क (arguments) लेता है। तो यह 2 लेता है, फिर पारित स्ट्रिंग की लंबाई unicode के रूप में, और एक वेरिएबल के लिए ptr
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/39e0d1d9baabff8d95da7109294db94f9fc4409a6ede34d37ece9662fb73651d.png" alt="2">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/e116e90f20a09d48f21a981e7d24c49f7474ea9ac6007b6fa41973300af4e83d.png" alt=""><figcaption></figcaption></figure>
</div>
अब यदि हम इसे डीबगर में निरीक्षण करें
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/f412c3bf83f60da9213f4c29b39350c925a0aa6411c42de52d7fa4530c5bc3fe.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/5285bf4d5e52dbbef857e46e8738c3ba6e7f6cda87f9b67a4965b23cc70aba0e.png" alt=""><figcaption></figcaption></figure>
</div>
हमें एक अजीब चीज़ दिखती है - rcx में एक डीबग स्ट्रिंग है जो AllocatePool है, जो एक फ़ंक्शन कॉल के बाद आती है, इसलिए हम निष्कर्ष निकालते हैं कि यह संभवतः AllocatePool के लिए एक कॉल थी। दिलचस्प बात यह है कि यदि आप स्पेक्स का निरीक्षण करें तो आप देखेंगे कि boot\_services में भी AllocatePool के लिए एक ptr है, जो केवल हमारी धारणा को मजबूत बनाता है।
बढ़िया, तो यदि हम पर्याप्त स्थान आवंटित करने में सफल हो जाते हैं (>= 0 की जाँच यह देखने के लिए है कि क्या हम आवंटन में सफल रहे, क्योंकि यदि EFI\_OUT\_OF\_RESOURCES को इस रूप में लागू किया गया है
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/bf08cd5dd33ad9ca16ff4e6a44a4cbfd51cd1f8b0300d9b6b44984c4306fcb6e.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/c28af9995294473937be13a6094de90cb57a688c83727617ca9f667c2705d7cd.png" alt=""><figcaption></figcaption></figure>
</div>
तो यह मानना ही सुरक्षित है
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/3741ef8be2dc989f601d26568907381f1847d29c0bf514add76485b0f0fef4b6.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/cdfc6ccb296659fc8156d4bfba6d777da8b2792e4af56677d0f0d57695932216.png" alt=""><figcaption></figcaption></figure>
</div>
सफल आवंटन के लिए उपयोग किया जाता है)
एक दिलचस्प तथ्य यह है कि आवंटन के बाद बफर शून्य (zero) नहीं होता, बल्कि इसमें ये बाइट्स होते हैं। यदि किसी को इसके बारे में अधिक जानकारी है तो कृपया इस दस्तावेज़ को संपादित करने के लिए pr अनुरोध करें
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/e4b15da615e07faa4965d864435bf4deec0e01270f9d1ac1134fb5b20ad46892.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/b229a700b321040fc8978f4f0f489a058381795c128d27dbcfbcfff5f9ffd3b2.png" alt=""><figcaption></figcaption></figure>
</div>
तो हाँ, वैसे भी हम अंततः memcpy को कॉल करते हैं, कॉल के बाद हमारा बफर ऐसा दिखता है
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/28e61d8725687245e9a9dae7e467929ac15d5a81e33178262f0ce886a3c4555c.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/f161ab0441b14d71dbade9fc3acebbd12b1453de5d53b77b09af98c0cf0ac6d6.png" alt=""><figcaption></figcaption></figure>
</div>
फिर हम बफर को ऐसा दिखाने के लिए कुछ बाइट्स जोड़ते हैं
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/80906384a49ef1d6eaea9667cb962459c27feb8e9deac857491a248be5443a4f.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/7c703952c72c154d156603c457a00013305c48519ddee808925c32a62499135f.png" alt=""><figcaption></figcaption></figure>
</div>
और फिर FileDevicePath\_call नामक एक फ़ंक्शन को कॉल करते हैं जो कुछ ऐसा दिखता है 
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/66c77ae12715ee6d982ba2cfb769ba6a650f52ce56d7bae54e3bd93686695f02.png" alt=""><figcaption></figcaption></figure>
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/5f7e06800ec3eecb9559d1592b8a76868038c0cbb64744e5c928b65d189ef183.png" alt=""><figcaption></figcaption></figure>
और यह इस रूप में अनुवादित होता है
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/2b36492bb7dd46a7139c27de61371b59adac5bfbec989bbb542b58d34ce7982d.png" alt="2">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/361e2b338c676b99393f7baa48e970ba886894f579065a4468fe113841c0783b.png" alt=""><figcaption></figcaption></figure>
</div>
बढ़िया, लेकिन बिना समझाए यह कोई मतलब नहीं रखता, इसलिए....
पहले हमारे पास strlen का एक कस्टम कार्यान्वयन है, जिसे हम विच्छेदित नहीं करेंगे क्योंकि यह बेकार है :) लेकिन यह रहा परिणाम
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/03a0aabe9f7c87f42b7e64bb284d74738ecdc81134136cfec68c70084644c3ea.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/823c30bd0a6a8c1d750ef1dfb0bce5be67a13a96de12e53b3e46b2226a1c2be1.png" alt=""><figcaption></figcaption></figure>
</div>
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/5dd4684c37f3129c8234cd69574bb6371b4bef72ff7e027199b7900134cdd101.png" alt="2">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/118ee749874a6b08d40286821735190f67af45ca8d4573fc94aee3a2cea04af2.png" alt=""><figcaption></figcaption></figure>
</div>
`len(of(str)+"\x00")` से 32 वर्ण, और फिर फ़ंक्शन कॉल से पहले जोड़े गए अंतिम 4 बाइट्स 0x4FF7F
अगला, हम उसे कॉल करते हैं जिसे मैंने एशियाई शोधकर्ता के शोध ब्लॉग पोस्ट PxepDevicePathInstanceCount से भी उपयोग किया था, जो केवल strlen है, क्योंकि यह केवल प्रत्येक अक्षर की गिनती करता है और एक काउंटर रखता है। जैसा कि यहाँ देखा गया है
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/130931a6676f0519da2b50a9762955b7581e7102434e587236137b216cc62ead.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/ce1a6ad93452a8092d2fb71ffd6418df78c32fc8cdf4fb99133924cc9037f12e.png" alt=""><figcaption></figcaption></figure>
</div>
तो हाँ, हम pop rbx देखते हैं और कॉल के बाद हम rbx=0x48 देखते हैं
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/4c2eabdd91ec40fc82c100e67579d729def9e74c6bfd000fff287bc9c10b0f38.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/818bb3c8398d4a53c0260d9310d4d192cfa5b65a404348df5516c94fa3d8dcaa.png" alt=""><figcaption></figcaption></figure>
</div>
फिर हम उसी स्ट्रिंग पर फिर से strlen को कॉल करते हैं, मुझे लगता है यह केवल इसलिए है क्योंकि अगली पंक्ति में, सटीक रूप से, `v6 + v4 * v5;` में हम v4\*v5 करते हैं, जो मुझे लगता है कि unicode स्ट्रिंग्स रखने का कुछ तरीका है
वैसे भी, फिर हम gEfiBootServices + 64 का उपयोग करके फिर से मेमोरी आवंटित करते हैं, जिसका हमने पहले सामना किया था और जो AllocatePool के रूप में हल हुआ था।
तो यहाँ हम कुछ अच्छा भी देखते हैं, जो है
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/26d19e06bd335f1267946a5da2542cf3eb9f2965fab788d0bcf720d7e3c08d37.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/225c92cbe9a5e72214cb279e61ad5fcbaef0a243db835b67fce5ff7ef74e7c86.png" alt=""><figcaption></figcaption></figure>
</div>
तथ्य यह है कि यहाँ मेमोरी ब्लॉक में afafafaf पैटर्न है।
तो आगे क्या होता है कि मुख्य लूप (main loop) निष्पादित होने के बाद हमें दो बफर मिलते हैं जो ऐसे दिखते हैं
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/35f257d96c752ac436e81778da5f37c28bfcb79fc5614f3ea8e099888cc011c3.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/b9c706cc28161a6e7274c5cabc895bedc1279728b3ed7c11084cb6cb38dbf9e3.png" alt=""><figcaption></figcaption></figure>
</div>
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/52477a3825650e47112a5e619a098c74e7e0de778ebfeda5682e5b49d48f3923.png" alt="2">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/762a6dd3897f3b630ce1d0faa371e58ed9b2bce755bb8edd54f958aab7c3b69b.png" alt=""><figcaption></figcaption></figure>
</div>
और सच कहूँ तो हमें केवल पहले वाले में रुचि है क्योंकि वही लौटाया जाता है, इसलिए हम निष्कर्ष निकाल सकते हैं कि यह केवल डिवाइस पथ की प्रतिलिपि बनाता है और बफर से कुछ कचरा साफ़ करता है। :))
अब जब हम यह समाप्त कर लेते हैं, तो हम जाँचते हैं कि क्या हमारे मामले में डिवाइस पथ पहले से आरंभीकृत है, और यदि नहीं तो पूल को मुक्त (free) करते हैं; हम पहले उल्लिखित फ़ंक्शन से साफ़ बफर लौटाते हैं।
इस फ़ंक्शन को समाप्त करने से पहले मैं एक और दिलचस्प तथ्य की ओर इंगित करना चाहूँगा, यह है कि bootservice तालिका मेमोरी में कैसी दिखती है :) यह स्पेक्स के अनुसार प्रारंभिक हेडर के साथ ऐसी दिखती है। बस सोचा कि इसे यहाँ रखना दिलचस्प हो सकता है, उन लोगों के लिए जो भविष्य में काम करना चाहते हैं और खुद को डंप में यह स्ट्रिंग BOOTSERVF पाते हुए देखें, यह निश्चित रूप से bootservice तालिका है
\=============================================================================
ठीक है, तो आगे क्या होता है??? हम जाँचते हैं कि क्या हम winload.efi फ़ाइल का पता लगाने में सफल हुए और हम इसे मेमोरी में लोड करते हैं। यह रहा स्यूडो कोड :)
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/b59f211cb997e5ad783cbb6421833c23bea4ef4f7f21743577cd8aba4656ad2f.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/a96f7410f6bd6f7e207b76dff36a411f3c17a3f40dcb1a9433d5292b46f775e2.png" alt=""><figcaption></figcaption></figure>
</div>
और यह मेमोरी में ऐसा दिखता है
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/e3ee7b08fdc84433a08e60c7065c74692fb3a4e26eb81def063b662aa5229558.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/445d40332ba97516eebf129d17c56a38e28688858515d787ebf90a99580daa51.png" alt=""><figcaption></figcaption></figure>
</div>
rax क्या है? rax इमेज के लिए एक हैंडल है :) मेरी तरह मूर्ख मत बनो, जब मैंने पहली बार सोचा था कि यह एक मेमोरी क्षेत्र है :)
बढ़िया, इससे पहले कि हम और आगे बढ़ें, मैं जल्दी से समझा दूँ कि winload.efi आखिर क्या है। तो, `कंप्यूटरों के विकास के साथ, पारंपरिक BIOS बूट पुराना हो चुका है, और UEFI बूट के बारे में सुरक्षा टकराव शुरू हो गया है। नीचे दिए गए प्रवाह चार्ट से, हम देख सकते हैं कि UEFI में MBR और VBR अब मौजूद नहीं हैं, बल्कि UEFI स्वयं bootmgr को लोड करने के लिए जिम्मेदार है, जिसका अर्थ है अधिक सुरक्षित और तेज़`
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/d2443977ce3d56790e424fd6236d1d0594db283caa9357ed4e6abb9b8b30b8ed.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/1259e1f45b2d2bb8edcb12609e057d089f7c1dcf907677973d799049c58bee4a.png" alt=""><figcaption></figcaption></figure>
</div>
तो एक सामान्य Windows पीसी कैसे बूट होता है? BDS के बाद, SPI में संग्रहीत UEFI फ़र्मवेयर कोड अपना काम पूरा कर चुका होता है, फिर UEFI फ़र्मवेयर बूट मैनेजर पहले ESP खोजने के लिए NVRAM UEFI वेरिएबल की जाँच करता है, और OS-विशिष्ट बूट मैनेजर bootmgfw.efi को ढूँढता है ताकि उसके प्रवेश फ़ंक्शन (DXE ड्राइवर) को कॉल कर सके।
यह फ़ंक्शन पहले EfiInitCreateInputParametersEx फ़ंक्शन को कॉल करेगा, जो मुख्य रूप से EfiEntry पैरामीटर को bootmgfw.efi द्वारा अपेक्षित पैरामीटर प्रारूप में परिवर्तित करने के लिए उपयोग किया जाता है।
फिर Windows Boot Manager की प्रवेश बिंदु BmMain फ़ंक्शन को कॉल किया जाता है।
इस फ़ंक्शन में, स्टार्टअप एप्लिकेशन (BootDirectory) पथ (\EFI\Microsoft\Boot) को आरंभीकृत करने के लिए BmFwInitializeBootDirectoryPath को कॉल किया जाता है।
फिर BootMgr सिस्टम बूट कॉन्फ़िगरेशन अक्षर (BCD) को पढ़ेगा, यदि कई बूट विकल्प हैं, तो यह बूट मेनू प्रदर्शित करने के लिए BmDisplayGetBootMenuStatus को कॉल करेगा।
फिर यह एप्लिकेशन (winload.efi) शुरू करने के लिए BmpLaunchBootEntry फ़ंक्शन को कॉल करेगा।
बेशक, bootmgfw.efi इससे अधिक काम करता है, जैसे बूट नीति सत्यापन कोड अखंडता और सुरक्षित बूट (secure boot) घटकों का आरंभीकरण, इसलिए मैं विवरण में नहीं जाऊँगा।
Windows Boot Manager (BootMgr) के अंतिम चरण में, BmpLaunchBootEntry फ़ंक्शन पिछले BCD मान के अनुसार सही बूट प्रविष्टि का चयन करेगा। यदि पूर्ण वॉल्यूम एन्क्रिप्शन (BitLocker) सक्षम है, तो सिस्टम पार्टीशन को पहले डिक्रिप्ट किया जाएगा, और फिर नियंत्रण winload.efi को स्थानांतरित किया जा सकता है।
इसके बाद, BmTransferExecution फ़ंक्शन को कॉल किया जाता है, स्टार्टअप विकल्पों की जाँच की जाती है और निष्पादन प्रवाह BlImgStartBootApplication फ़ंक्शन को पारित किया जाता है।
फिर BlImgStartBootApplication फ़ंक्शन ImgFwStartBootApplication फ़ंक्शन को कॉल करेगा, और अंत में ImgArchStartBootApplication फ़ंक्शन को कॉल करेगा। इसमें, winload.efi का मेमोरी सुरक्षा मोड आरंभीकृत किया जाएगा, फिर BlpArchTransferTo64BitApplication फ़ंक्शन को कॉल करेगा, BlpArchTransferTo64BitApplication Archpx64TransferTo64BitApplicationAsm फ़ंक्शन को कॉल करता है जो अंततः नियंत्रण winload.efi को सौंप देता है।
यह फ़ंक्शन नए GDT और IDT को सक्षम करेगा, और फिर पूरी तरह से नियंत्रण winload.efi को सौंप देगा। इस बिंदु पर, BootMgr अपना मिशन पूरा कर लेता है और Winload काम करना शुरू कर देता है। - उद्धरणों का अंत, एक चीनी वेबसाइट से लिया गया है जो इसके बारे में बात करती है (अधिक सामग्री के लिए कृपया इसकी समीक्षा करें https://bbs.kanxue.com/thread-268267.htm )और वहाँ से winload.efi अपना काम करता है, जो विंडोज़ को लोड करना और कुछ और हार्डवेयर (hw) कार्य करना है, इससे पहले कि वह नियंत्रण कर्नेल को सौंपे।
अब इस संक्षिप्त ब्रीफिंग के बाद, जैसा कि हम कह रहे थे
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/65537ae888c278e8e487029f93d909fb1e4699069699cf1b7d5ad8fa1f9e0d69.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/3b00c68a215f4568fca5d672ea6f892fecf9809e671c68795c067d2660fa3f1f.png" alt=""><figcaption></figcaption></figure>
</div>
हम आगे जाँचते हैं कि क्या इसे मेमोरी में लोड करना सफल रहा, और फिर हम ati\_analysis\_rdtsc\_aia\_cu\_4e1f नामक एक फ़ंक्शन कॉल करते हैं, जिससे आप परिचित होंगे यदि आपने इस विश्लेषण का पहला भाग पहले ही पढ़ लिया है।
अब मज़े के लिए, मान लेते हैं कि हम उस फ़ंक्शन का विश्लेषण करने में विफल रहते हैं और हम पकड़े जाते हैं। आइए देखें कि sub\_180002A08 कैसा दिखता है।
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/4eb3ae379ab937e19e6a699339d992b2a5fd1fcb33202ca67355f62a5b1203b4.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/a4b252df16a31b5bf165d2a500ebe3c54ad5dad3c58cf9fe88a8a1da11ed6b63.png" alt=""><figcaption></figcaption></figure>
</div>
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/dd594955a663274e25603804c348b516ca22755886b2732ef81dc8e1e0177544.png" alt="2">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/6fba01328584e8abb254912b81b048e8dcf80bda6d3eadc11573a52a5e84dd15.png" alt=""><figcaption></figcaption></figure>
</div>
हम फिर से gEfiSystemTable + 64 देखते हैं, जिसे हम इस बार वास्तव में नहीं जानते, क्योंकि यह अलग प्रकार का है — इस बार यह bootservices प्रकार का नहीं है, बल्कि efisystemtable प्रकार का है। फिर memcpy और एक और 3 फ़ंक्शन कॉल हैं, जिन्हें हम अभी नहीं जानते, यदि हम लूप शुरू होने तक चलाते हैं।
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/20e0db7308860023b613310ea14e0880529a588540d9dabac2218b52dc93cefb.png" alt="2">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/b8f498165a4016c19d8d5797517680fc32dea241d343b38fcc613620270d58dd.png" alt=""><figcaption></figcaption></figure>
</div>
और यदि हम memcpy के पिछले पैरामीटरों का निरीक्षण करें
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/21f546fbfb10a39e0e603186c8c505a3ae0679e8c7bad40f31643022f9ebfbcd.png" alt="2">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/2ef8c97938b8f961abf92c03937ca15d5a48cd03eb58a0169891559fad27dde5.png" alt=""><figcaption></figcaption></figure>
</div>
और हम qemu के आउटपुट इमेज का निरीक्षण करते हैं, तो हमें मिलता है
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/e4325617bfda31fb45f7920d0d1d977103fd6b85260e590fc7cfdca1efacb787.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/04e29142b4cf543a6e5b8f55de2c27d1f3f0034707a6d19e2b1ea45b8251e899.png" alt=""><figcaption></figcaption></figure>
</div>
बढ़िया, तो आइए इसका कुछ अर्थ निकालें। मैं फिर से एशियन के शोध ब्लॉगपोस्ट का संदर्भ लूँगा, क्योंकि सच कहूँ तो मैं यहाँ खो गया हूँ।
तो अपने ब्लॉग पर वह कहता है कि वे दो फ़ंक्शन वास्तव में थे```
ConOut->ClearScreen(ConOut);
ConOut->OutputString(ConOut, String);
ठीक है, लेकिन conOut आखिर है क्या? वैसे वह यह भी कहता है कि conout EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL प्रकार का है और conout ConOut = gEfiSystemTable->ConOut; द्वारा प्राप्त होता है। ठीक है, तो कोड में इसका क्या मतलब है??
ठीक है, तो चलो गहराई में जाते हैं
परिभाषा
और guid
अब मेरा चतुर दिमाग़ वास्तव में इसे डीबगर में कैप्चर करना भूल गया, क्योंकि जब मैंने पहली बार इसका विश्लेषण किया तो मैंने efisystemtable और bootservices के बीच डेटा टाइप को भ्रमित कर दिया और मैंने सोचा कि यह वास्तव में allocatepool है।
अब वे फ़ंक्शन क्या करते हैं?
खैर, ClearScreen काफी स्व-व्याख्यात्मक होना चाहिए और OutputString भी। शोधकर्ता इस निष्कर्ष पर कैसे पहुँच सकता है कि वह वेरिएबल EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL प्रकार का है? खैर, शायद उसने डीबगर में guid बाइट्स देखे थे।
अब आखिरी फ़ंक्शन के बारे में क्या?
खैर, अपने ब्लॉगपोस्ट में वह कहता है कि आखिरी फ़ंक्शन gEfiBootServices->Stall है? तो यह आखिर करता क्या है? UEFI स्पेक्स के अनुसार The Stall() function stalls execution on the processor for at least the requested number of microseconds. Execution of the processor is not yielded for the duration of the stall.
तो मूल रूप से यह हमारे CPU को फ्रीज़ कर देता है। कितनी देर के लिए? 0x1C9C380 सेकंड। मुझसे पूछो तो बहुत लंबा समय है। जो फिर से एक अनंत लूप में डाल दिया गया है, तो हाँ, हम खत्म हो गए :)))
और डीबगर में यह ऐसा दिखता है
अब अपने मुख्य फ़ंक्शन के साथ जारी रखते हुए
अगर हम bootmgfrw.efi लोड करने में सफल होते हैं (क्योंकि यहाँ winload.efi असली Windows bootloader है) तो हम sub_180002538 को कॉल करते हैं
============================================================================= sub_180002538
ग्राफ़ के दृष्टिकोण से
ASM के दृष्टिकोण से
क्या अब कुछ याद आ रहा है? नहीं? खैर, एक मिनट दो, यह दिमाग़ में आ जाएगा। इस बीच, स्यूडो-कोड के नज़रिए से देखें
हम किसी exe का कुछ पार्सिंग देखते हैं :) अब मुझे नहीं पता कि यह पिछले भाग (part1) वाले से कितना मेल खाएगा, लेकिन चलो देखते हैं :)
तो हम अपने बाइनरी (bootmgfrw.efi) के मेमोरी में मौजूद संस्करण की तुलना क्लासिकल MZ हेडर (0x5A4D) से करते हैं, जैसा कि आप देख सकते हैं
ठीक है, अगला हम एक और क्लासिक जाँच करते हैं, जो यह देखना है कि क्या हम PE हेडर ढूँढ सकते हैं
बढ़िया, अगला हम sub_1800024C4() कॉल करते हैं जो कुछ ऐसा दिखता है
बढ़िया, तो यहाँ क्या होता है कि हम मेमोरी में कुछ विशेष मान ढूँढते हैं और अगर वे मिल जाते हैं तो उन्हें लौटा देते हैं। कृपया इम्यूलेशन के लिए sub_180002538.py.py देखें।
वैसे भी, यह रहा sub_180002464
अगर हम sub_1800024C4 को सफलतापूर्वक निष्पादित कर लेते हैं, तो हम बड़े फ़ंक्शन में लौटते हैं और कुछ और जाँचें करते हैं। बढ़िया, चलो इनका कुछ अर्थ निकालते हैं
बढ़िया, तो हम आगे rax+0xe पर जो कुछ भी है उसकी तुलना 0x64 से करते हैं, हम्म दिलचस्प। rax+0xe का निरीक्षण करते हैं
क्या इस विशेष जाँच के पीछे कोई खास कारण है? ईमानदारी से कहूँ तो मुझे नहीं पता। हो सकता है, अगर आपको पता हो तो कृपया एक pull request बनाएँ और इस दस्तावेज़ को संपादित करें
हम कुछ और जोड़ते हैं और फिर एक तुलना करते हैं
मैं यहाँ एक मिनट रुकना चाहता हूँ और जब भी मैं भ्रमित हुआ, इस लेख के लिए प्रेरणा के पिछले स्रोत का फिर से उल्लेख करना चाहता हूँ। तो अपने ब्लॉग में उसने उस फ़ंक्शन का नाम बदलकर RtlpImageDirectoryEntryToDataEx रख दिया, जो मानों की तुलना करता था। अगर हम खोजें तो हमें कोई परिणाम नहीं मिलता, लेकिन उसके नाम के काफी करीब कुछ है और वह है RtlImageDirectoryEntryToData, जो मूल रूप से यह करता है Given the base address of a kernel module and the index of an entry in the data directory, RtlImageDirectoryEntryToData() returns the virtual address and the size of the directory entry(https://codemachine.com/articles/top\_ten\_kernel\_apis.html)। हमारे मामले में, चूँकि हम एक efi/uefi ऐप में हैं, हम मान सकते हैं कि जो 50 हम देख रहे हैं वह हमारे रूट पार्टीशन के बाइट्स/एमबी का आकार है, मुझे नहीं पता यहाँ, और rax में जो पता है वह हमारी डायरेक्टरी में एक एंट्री है।
इससे आगे बढ़ने से पहले एक और दिलचस्प विवरण समझाया जाना बाकी है। अपने शोध में वह RtlImageDirectoryEntryToData के आउटपुट को इस संरचना में बदलता है``` typedef struct _IMAGE_RESOURCE_DIRECTORY_ENTRY { union { struct { DWORD NameOffset : 31; DWORD NameIsString : 1; }; DWORD Name; WORD Id; }; union { DWORD OffsetToData; struct { DWORD OffsetToDirectory : 31; DWORD DataIsDirectory : 1; }; }; } IMAGE_RESOURCE_DIRECTORY_ENTRY, *PIMAGE_RESOURCE_DIRECTORY_ENTRY;
अब इस स्ट्रक्चर के बारे में क्या बकवास है ?
खैर, उस स्ट्रक्चर के बारे में त्वरित खोज करने पर हम यहाँ पहुँचते हैं(http://www.brokenthorn.com/Resources/OSDevPE.html) जो हमें बताता है कि `Parsing resources is a bit more complex then the other directory types, however. Like the other sections, there is a base IMAGE_RESOURCE_DIRECTORY structure that can be obtained from the DataDirectory member of the optional header: blah blah` और यह भी कि \`\`\`This structure doesnt have much of any interesting fields, except the last three.
If you have worked with Win32 resources, you might know that resources can be idenitified by ID or name. Two of the members in this structure will let us know the number of these entries, and the total amount of entries (NumberOfNamedEntries + NumberOfIdEntries), which is useful in looping through all of the entries. As you can probably guess, the entries are in the DirectoryEntries array. DirectoryEntries consists of an array of IMAGE\_RESOURCE\_DIRECTORY\_ENTRY structures, which follow the format:\`\`\`
तो असल में यह चीज़ आंतरिक रूप से पार्सिंग के लिए उपयोग होती है और हमारे लिए इस संदर्भ में समझ में आता है कि हम एक ऐसी डायरेक्ट्री के साथ काम कर रहे हैं जिसमें रिसोर्सेस हैं, बढ़िया।
और चाहिए!
तो आगे क्या है
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/137d3d2aebf0db9501f550b09baddf01c3e50bf703ca8d13386a7185a567f19a.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/045c3a8a2bab306f516cdc7e9a59954e3c1ff16efe4189273c50f54b9e84f3e6.png" alt=""><figcaption></figcaption></figure>
</div>
यह जो करता है वह मूल रूप से डायरेक्ट्री के हर रिसोर्स पर iterate करता है और देखता है कि क्या वह string प्रकार का है।
सच कहूँ तो मुझे नहीं पता वह ऐसा क्यों करेगा। अगर मैं गलत हूँ तो माफ़ करना, अगर सही हूँ तो चियर्स!
आगे
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/a57c5815ee8b5498fed6d8dde92f48b9fc2bdfd2d4f4e231796ba96e5e28bea9.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/bd4513fdf1f8f165fc404b8462d6bc36644de4937e42d560d54f1a5f1c0e8799.png" alt=""><figcaption></figcaption></figure>
</div>
तो यहाँ क्या होता है कि हम कुछ offsets जोड़ते हैं और उस जगह पहुँचते हैं जिसे चीनी रिसर्चर दूसरी resource table कहता है, जैसा कि आप देख सकते हैं
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/8f6655fb8117abf8a4d38b5173d51e4bc3ce67b86803c57cce36d47b73cd1e76.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/ebdf5a9a749f2cb1b7a656be5f2d99419edfc9cd2a737e15c6845f2c008e3f11.png" alt=""><figcaption></figcaption></figure>
</div>
और फिर हम कुछ offsets पाने के लिए वही प्रक्रिया दोहराते हैं
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/faa12c96d0b22e6128ef1cdf14110c31cc9ebca89325f28a07fc6a0a064daeba.png" alt="2">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/216539eaf48a407a7f691d10cca06679a545471c3e54f25fedb31c38f0c61a66.png" alt=""><figcaption></figcaption></figure>
</div>
और उसी प्रक्रिया को दोहराते हैं, इस बार हम VS\_VERSION\_INFO प्रकार की जाँच करते हैं
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/ac2d2e82085f4ddbc3f5ae1ce35528dd8420924b0298c65db056d0837c3e4b6d.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/23788c642b82988c14654e9dac2afd2504cd22846be0487efce96cae4d6fe094.png" alt=""><figcaption></figcaption></figure>
</div>
तो VS\_VERSION\_INFO आखिर है क्या? खैर, माइक्रोसॉफ्ट(https://learn.microsoft.com/en-us/windows/win32/menurc/versioninfo-resource) कहता है कि `Defines a version-information resource`, यानी मेरा मानना है कि यह केवल bootmgfrw.ef का वर्शन बताता है।
और अंत में अगर हमें VS\_VERSION\_INFO मिलता है तो हम वही एल्गोरिदम दोहराते हैं
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/4f00ecf2c2c9b32b2d25fcbf3c62e9bb45679df1390a085371f5166a70d67933.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/facd25069491b5d7826500e4f2c04cafe213191075012ddb4c1fa9a8bc97c4c5.png" alt=""><figcaption></figcaption></figure>
</div>
इस बार एक twist के साथ, और twist यह है कि हम build id लौटाते हैं :) जैसा कि हम देख सकते हैं
तो निष्कर्ष के तौर पर, यहाँ असल में क्या हुआ? खैर, चीनी रिसर्चर द्वारा इस्तेमाल किए गए नाम(GetPeFileVersionInfo\_BuildNumber\_) के आधार पर हम यह निष्कर्ष निकाल सकते हैं कि हमें वास्तव में bootload का build number मिलता है, जैसा कि पहली छवि में देखा जा सकता है
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/b28007dda110fc31d53233931ff077ac42fc81146d803b91999069e204020a4d.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/d19f1311c2ee242ced63da8334db384929ada3acae147009becc0dbf34d2b7fb.png" alt=""><figcaption></figcaption></figure>
</div>
जहाँ यहाँ हम memory में load किए गए bootload को देखते हैं
दूसरी छवि में हम देखते हैं
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/2000f17c51ccc65267b46ac2c1d191bd033b3bc6e6b655973423dbbd8a1fc77e.png" alt="2">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/7c47fe45fe4b422618a400f2c26c28cd33fea9416f2b24086a2c852d08f1614b.png" alt=""><figcaption></figcaption></figure>
</div>
rcx में एक integer जो या तो build nr हो सकता है या pefileversion
और तीसरी छवि
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/41729b1d4a4701480d64f058f421cd2ad8a8b9b871bf17675fd7b537cec3dd85.png" alt="3">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/d2b17725eeb9af2336d725be9c556565fba221fd2a3517912c942f411f9ed33b.png" alt=""><figcaption></figcaption></figure>
</div>
जिसे हम build number होने का अनुमान लगा सकते हैं क्योंकि ebx को rax में move किया जाएगा :)
तो इस फ़ंक्शन पर अंतिम टिप्पणी: वाह, अद्भुत इंजीनियरिंग।
\=============================================================================
अब अगली चुनौती पर :) पिछले stage के आउटपुट के आधार पर हम v10 को sub\_180001D80 या sub\_180001D48 पर set करते हैं, जैसा कि देखा गया है
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/33581031e03f29b5997d46b708c467bfd49ce58625e99381dd28c109cadae7d3.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/6647119081cffb664dcca365392271398b2572ee04c24a0456141f33cbaaeecf.png" alt=""><figcaption></figcaption></figure>
</div>
और हमारे मामले में v10=sub\_180001D80
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/2af043a1449f6bf10e2925f06697438716976d24a1539a61ab42c4301c4a8435.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/0769d4dff6e1da51acaf9c5bac3a9a9b4b446aae9d7c593e7e54d865ec13c2ea.png" alt=""><figcaption></figcaption></figure>
</div>
\=============================================================================
फिर हम अपने bootloade manager और उस बाइट्स array के बीच strcmp करते हैं
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/59164794afc69304133f0a4c008b9e4755671e8d57bd8dc4ea5a2b2e6ae54164.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/03b00f7c18ff7db73dfd5253f02d6966955e38732fa7d1cfb4840366c17355a1.png" alt=""><figcaption></figcaption></figure>
</div>
मैं यहाँ थोड़ी देर रुकना चाहता हूँ, क्योंकि जैसा कि आपने शायद अनुमान लगाया होगा, मुझे चीनी रिसर्चर के ब्लॉग पोस्ट में कुछ दिलचस्प लगा। उसने बाइट्स array को SigImgArchStartBootApplication नाम दिया था। तो SigImgArchStartBootApplication आखिर है क्या, और यह किसका है, और आखिर उस array को ऐसा क्यों कहा गया है(migos)? तो अगर हम google(gulugulu) पर SigImgArchStartBootApplication खोजते हैं तो हमें कुछ नहीं मिलता। अब, वर्तमान संदर्भ को देखते हुए हम Windows के bootloader manager का उपयोग करते हैं, चलिए इसे IDA में खोलते हैं। हम C:\Windows\Boot\EFI पर जाते हैं, binary को ida में खोलते हैं और SigImgArchStartBootApplication खोजते हैं, कुछ नहीं। हम ImgArchStartBootApplication खोजते हैं और हमें यह मिलता है
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/1ad42d5236e8ca4da08688fe3d4c72e6b3de01fdce633a1bdaa870de421cdc40.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/d6e211aa12b37dfba0244d48516a08703248484c070f8d7ffcf0a28f08e8a833.png" alt=""><figcaption></figcaption></figure>
</div>
तो ImgArchStartBootApplication .... ये क्या कर रहा है... !? खैर, अम्म...ह्ह, मैं इसे `@_xeroxz` से चुराऊँगा(जाओ उसे follow करो, अगर तुम उसका काम follow नहीं कर रहे तो क्या कर रहे हो....) तो मूल रूप से एक article में वह कहता है कि `bootmgfw.ImgArchStartBootApplication between windows versions 2004-1709 is invoked to start winload.efi` जैसा कि हम उसकी छवि से भी देख सकते हैं(https://guidedhacking.com/threads/hyper-v-hacking-framework-works-on-every-version-of-windows-10-2004-1511-amd-intel.16251/)
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/4967559cb05e49785841a2dc216e13fc0b94fe8be8f17d9bceaf1914722156ff.jpg" alt="1603213912596">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/4967559cb05e49785841a2dc216e13fc0b94fe8be8f17d9bceaf1914722156ff.jpg" alt=""><figcaption></figcaption></figure>
</div>
अगर यह पर्याप्त स्पष्ट नहीं था, एक article() में हम देखते हैं कि `ImgArchStartBootApplication to catch the moment when the Windows OS loader (winload.efi) is loaded in the memory but still has not been executed`(https://rustrepo.com/repo/rusty-bootkit--uefi-bootkit-in-rust)
ठीक है, तो strcmp का ImgArchStartBootApplication से क्या लेना-देना? खैर, आइए IDA पर ध्यान से देखें और जल्द ही उत्तर सामने आ जाएगा, अगर हम bootloader कोड में 41 b8 09 बाइट्स खोजते हैं तो हमें जल्द ही असली अपराधी मिल जाता है
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/91050c01f95eb88488cbc575c21af7f453228eeb13c665b94d415eecf5682a55.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/7239d85f2dc9e220a2eab80f79b5db9705285a17c074f85958c041d122bfaf8e.png" alt=""><figcaption></figcaption></figure>
</div>
और यदि हम memory में मौजूद अपने bootloade image bytes को बाइट्स के signature से match कर लेते हैं तो हम sub\_180002398 execute करते हैं
और निश्चित रूप से जैसा कि देखा जा सकता है, हमने pattern का पता लगा लिया, हमें eax में वह memory zone लौटा मिला जहाँ बाइट्स हैं, और हम सुरक्षित रूप से sub\_180002398 चलाने के लिए आगे बढ़ते हैं
\=============================================================================
sub\_180002398
"Assembly perspective"
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/5aa624d92161499019e7ce6597bf46853c59ba89d37fec483a8ac7ee168ddbeb.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/afbf940a1eb535d73dce744606cc63c568c2b447c9cf85034c422a8e900859f4.png" alt=""><figcaption></figcaption></figure>
</div>
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/6468513a220946bbccfab53328c056a620755e1fe94ad3e36d8c8958ed777794.png" alt=""><figcaption></figcaption></figure>
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/c5c36e7c29f1cdea6f42d55d7605ad3c2044d66397c867c221da6c0bf74f8d6a.png" alt=""><figcaption></figcaption></figure>
"Pseudo-code perspective"
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/5b1d8a264dad55f34a0cc958a2f4a26014a31987af5b66754e754589ea085097.png" alt="3">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/1d3db7165e0f71a3fa76862ba8afb3869f821f59db6fc5a5c5e99d5002ecfba1.png" alt=""><figcaption></figcaption></figure>
</div>
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/ae65504884fa2881cb50af2f88e846a0ad029c9431ee6296b28993de8f2e4a0d.png" alt=""><figcaption></figcaption></figure>
तो यह क्या कर रहा है? सच कहूँ तो यह कुछ गणना और कुछ जोड़-घटाव करता है, और कुछ खास महत्वपूर्ण नहीं? क्यों? क्योंकि यह उतना दिलचस्प नहीं है। हमें जिस चीज़ में दिलचस्पी है वह यह है कि function से लौटने के बाद क्या होता है। हम rax देखते हैं
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/4eae862955421b2b1629c120bb09970714cf085e9255590d6cfa36a77bbc69e9.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/43917bf46096449ad92172baa282fd3e70ec0bec67fec2bbf2a276285d878b52.png" alt=""><figcaption></figcaption></figure>
</div>
ठीक है, cool, फिर भी मुझे समझ नहीं आया। खैर rax = 0x5eec108 जो 0x48c48b48 की ओर इशारा करता है, ठीक है, तो? खैर, मैं भी उतना ही भ्रमित था जितना आप हैं, इसलिए मैं एक बार फिर चीनी ब्लॉग पर लौटा। तो वह रिसर्चर जो बताता है वह यहाँ यही होता है: यह ImgArchStartBootApplication function की शुरुआत में वापस जाता है। लेकिन उसे यह कैसे पता चला? खैर, जैसा कि पहले बताया गया, rax =\
0x48c48b48 और अगर हम booloadermnfr.efi का निरीक्षण करें तो हम देखते हैं
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/2dbe283fa0b0dd9cf837e79f1f42eaeb6dcd61252e76979c0a4af3cf2f68e8d8.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/624e1927cac5a0011d6fabea0f2ce4740b8dfd14102509656d6e5c0395a9c08d.png" alt=""><figcaption></figcaption></figure>
</div>
जो 0x5eec108 में बाइट्स का बिल्कुल वही sequence है। ठीक है, अब यह बढ़िया है :)
कृपया sub\_180002398.py देखें, इस व्यवहार को emulate करने का मेरा असफल प्रयास देखने के लिए :)
\=============================================================================
ठीक है, आगे?
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/432ad1832fa35743bc5676f7f8362ad9e2043e17387121136a1f6dfe1bdf16f1.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/aab798c5c80621b1c367ea6eecfff0d7caf9ecc368ae2fe2e947538e4f0e2b0c.png" alt=""><figcaption></figcaption></figure>
</div>
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/f04ebd9c650ddadb5553e4f2c43c72af8a5ccbef372a4dbdc811600e9583b0c9.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/3411e1620450739ea98f6db634346748487377106547324591b148cefe358df2.png" alt=""><figcaption></figcaption></figure>
</div>
तो आगे जो होता है वह है RaiseTPL। ठीक है, तो यह क्या करता है? यह वर्तमान में execute हो रहे task की priority बढ़ाता है और उसका पिछला priority level लौटाता है। हमारे मामले में यह सर्वोच्च execution privileges के साथ चलेगा।
आगे हम उस चीज़ को call करते हैं जिसे मैंने patch\_something नाम दिया है, जो इस प्रकार दिखता है
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/0a31b0c154406b340e9bb044c4211afd6494bcac6ec197c99a10a6d0effb6a31.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/3fcff1b34a5d9af3cdd70e4dac1188abd3edd13e74d11e4f0bba5d667d4f53a1.png" alt=""><figcaption></figcaption></figure>
</div>
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/c2f9bb8ca36961def04d4a3111a7d4213bb219949d13094b525a1a906ab788f7.png" alt="2">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/accdd93e3428b9b03132eafceda3ec5e1cfda742a978f1cd7f2c6bcf1904ceaa.png" alt=""><figcaption></figcaption></figure>
</div>
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/e0f6c806d296e47269b9908ceab7b90954bbd219d3d9c13462ebee8344f854f3.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/1ed164077989d04273ae3b40ec6daf7cf9b93ec42d917533b1e9758525231b7b.png" alt=""><figcaption></figcaption></figure>
</div>
तो static analysis से हम देख सकते हैं कि इसे hooking के रूप में जाना जाता है। :) तो मूल रूप से यह ImgArchStartBootApplication के bytes को patch करता है ताकि वे sub\_180001D80 की ओर इशारा करें और ImgArchStartBootApplication के original function को byte\_180015C78 में save कर देता है
और जैसा कि हम देख सकते हैं, यह बिल्कुल sub\_180001D80 में बदल जाता है
<div>
<img src="https://assets.kitploit.com/production/public/readmes/44336/6c48bf4c9126a9a1466493aed943113cc27b4bbf9f7d68cdd251d0e14303ad8a.png" alt="1">
<figure><img src="https://assets.kitploit.com/production/public/readmes/44336/633d84a62c16dba91229fe6bb73ed0318719fc06f63f7f2a9d19adba0d0e8cfe.png" alt=""><figcaption></figcaption></figure>
</div>
आगे हम privileges को reset करते हैं और वहाँ से नियंत्रण boomgrfw.efi को सौंप देते हैं :)
तो यह आधिकारिक तौर पर विश्लेषण का पहला भाग पूरा होने का संकेत है :) अगले भाग में हम सीखेंगे कि sub\_180001D80 और boomgrfw.efi(हमारे मामले में winload.efi) को और अधिक debug कैसे करें। तो कृपया बने रहें जब तक मैं विश्लेषण के दूसरे भाग के लिए environment तैयार करना नहीं सीख लेता।
\=============================================================================
अब विश्लेषण के दूसरे भाग के लिए.... हम boomgrfw.efi को debug कैसे करें?