slot2

slot2: एक दो-चरणीय UEFI GRUB2 बूटकिट जो AWS EC2 UEFI x86_64 पर Amazon Linux 2023 में एक प्री-OS नेटवर्केड इम्प्लांट को बनाए रखता है।

by cenobyte [email protected] 2026

https://github.com/cenobyte-vincit/slot2

सारांश

slot2, EC2 पर Amazon Linux 2023 के लिए एक बूटकिट है। AWS EC2 UEFI फ़र्मवेयर इसे सबसे पहले लोड करता है। एक एम्बेडेड इम्प्लांट स्टॉक OS के बूट होने से पहले बूटकिट UKI (यूनिफाइड कर्नेल इमेज: एक EFI फ़ाइल जिसमें बूटकिट कर्नेल और initrd होता है) के भीतर चलता है, नेटवर्क सहित, फिर सामान्य बूट में जिस स्टॉक कर्नेल का उपयोग होता, उसे शुरू करने के लिए kexec का उपयोग किया जाता है। जो ऑपरेटिंग सिस्टम आता है वह वास्तविक, स्टॉक वाला होता है।

पर्सिस्टेंस एक UEFI NVRAM लोड विकल्प और दो फ़ाइलों के माध्यम से होता है: एक बूटकिट ESP फ़ाइल और एक बूटकिट UKI; किसी यूज़रस्पेस हेल्पर/रूटकिट सेवा का उपयोग/आवश्यकता नहीं होती, और न ही कोई बदला हुआ वेंडर बूटलोडर होता है। slot2 में, 98-payload.sh वह इम्प्लांट है जिसका उपयोग प्री-बूट C2/infil/exfil और टारगेट के फ़ाइलसिस्टम पर RAT या कर्नेल-आधारित रूटकिट जैसे पेलोड डालने के लिए मनमाने डिस्क राइट के लिए किया जाता है। इस ट्री में इम्प्लांट एक प्रदर्शन है: यह /root/HELLO.TXT लिखता है और इंटरनेट/नेटवर्क कनेक्शन स्थापित करने के लिए नेटवर्क को ऊपर लाता है, जो एक ऑपरेशन में नेटवर्क इन्फिल या एक्सफिल हो सकता है।

बूट श्रृंखला

UEFI फ़र्मवेयर अपने आप कर्नेल नहीं चुनता। यह NVRAM लोड विकल्पों के BootOrder में चलता है, जिनमें से प्रत्येक एक क्रमांकित स्लॉट (Boot0001, Boot0002, ...) होता है जो ESP पर एक EFI निष्पादन योग्य की ओर इशारा करता है। EC2 पर, Boot0001 हमेशा मौजूद रहता है: Amazon EBS प्रविष्टि जो स्टॉक \EFI\BOOT\BOOTX64.EFI शुरू करती है। slot2 Boot0002 जोड़ता है, जो उसी ESP पर एक दूसरी फ़ाइल की ओर इशारा करता है, और Boot0002 को BootOrder पर पहले रखता है। फ़र्मवेयर के पास फिर भी Boot0001 फ़ॉलबैक के रूप में रहता है।

उस दूसरी फ़ाइल को कुछ ऐसा होना चाहिए जिसे फ़र्मवेयर निष्पादित कर सके, और उसे रूट फ़ाइलसिस्टम पर बूटकिट UKI तक पहुँचना होता है, जिसे फ़र्मवेयर देख नहीं सकता। GRUB का उपयोग किया जाता है क्योंकि वह GPT और XFS पढ़ सकता है, UKI ढूंढ सकता है, और उसे चेनलोड कर सकता है। इमेज एक कस्टम grub2-mkimage है, न कि पैकेज्ड Amazon GRUB; स्टॉक BOOTX64.EFI वहीं रहता है जहाँ वेंडर ने रखा था। यहाँ GRUB का एकमात्र काम UKI को हैंडऑफ़ करना है।

UKI कर्नेल फिर 98-payload.sh चलाता है, उसके बाद 99-kexec-stock.sh सामान्य BLS बूट में जिस स्टॉक कर्नेल और initrd का उपयोग होता, उसे शुरू करने के लिए kexec का उपयोग करता है।

  EC2 UEFI NVRAM
  ├── Boot0001 -> stock \EFI\BOOT\BOOTX64.EFI     (untouched)
  └── Boot0002 -> bootkit \EFI\BOOT\.BOOTX64.EFI  (created; first on BootOrder)
       |
       v
  ESP (VFAT)  /boot/efi
  └── /EFI/BOOT/
      ├── BOOTX64.EFI          stock (untouched) <- Boot0001
      └── .BOOTX64.EFI         bootkit GRUB2 PE  --chainload--+  <- Boot0002
                                                              |
  root FS (XFS, typical AL2023)                               |
  └── /var/lib/systemd/boot/                                  |
      └── uki.efi  <------------------------------------------+
            |
            |  98-payload.sh, then 99-kexec-stock.sh
            |  resolve stock target under /sysroot/boot/:
            |    loader/entries/*.conf  (BLS + grubenv; AL2023 primary)
            |    grub2/grub.cfg         (legacy fallback)
            |
            +-- kexec ----------------------------------------+
                                                              |
  /boot (stock, untouched)                                    |
  ├── vmlinuz-*  <--------------------------------------------+
  └── initramfs-*.img
            |
            +-- stock initrd -> stage-2 stock userspace

यदि kexec विफल हो जाता है, तो स्टेज 1 UKI कर्नेल पर जारी रहता है। मशीन बूट करने योग्य बनी रहती है।

पेलोड

इम्प्लांट 98-payload.sh है, जो बूटकिट UKI के भीतर एक dracut प्री-पिवट हुक है। यह बूट-पश्चात यूज़रस्पेस सेवा नहीं है। इस ट्री का कार्यान्वयन एक डेमो है: /sysroot को रीड-राइट रीमाउंट करना, /root/HELLO.TXT लिखना, NIC को ऊपर लाना, DHCP, फिर wget ifconfig.me (5 सेकंड का बजट)। नेटवर्क विफलता kexec को अवरुद्ध नहीं करती।

स्टेज 1 में असली रूट /sysroot पर होता है (सामान्यतः XFS, rw रीमाउंटेड)। /boot वास्तव में /sysroot/boot है। अतिरिक्त EBS वॉल्यूम तब तक माउंट नहीं होते जब तक हुक उन्हें माउंट न करे। स्लिम initrd में busybox udhcpc और wget शामिल हैं। ip(8) रियल-रूट बाइनरी है, जिसे initrd लोडर के माध्यम से चलाया जाता है।

आवश्यकताएँ

रनटाइम होस्ट

रनटाइम होस्ट टारगेट है (वह EC2 इंस्टेंस जो deploy चलाता है और फिर बूटकिट में रीबूट होता है)।

• Amazon Linux 2023 x86_64
• EC2 इंस्टेंस जो AMI बूट मोड uefi या uefi-preferred के साथ UEFI का समर्थन करते हैं
• रूट
• ESP /boot/efi पर माउंटेड (systemd ऑटोमाउंट ठीक है; deploy इसे ट्रिगर करेगा)
• libefivar और libefiboot (deploy डायनामिक रूप से लिंक्ड है; दोनों स्टॉक OS के साथ आते हैं)

ARM64 / Graviton का परीक्षण नहीं किया गया है और इसलिए समर्थित नहीं है (अभी?)।

बिल्ड होस्ट

Amazon Linux 2023 x86_64।

• ./install-dependencies.sh के लिए रूट
• चालू कर्नेल का /boot/vmlinuz-$(uname -r) और /boot/initramfs-$(uname -r).img (वे फ़ाइलें UKI में पैक की जाती हैं)
• cc, make, pkg-config, grub2-mkimage, objcopy, kexec, openssl, xxd

./install-dependencies.sh बूटस्ट्रैप है। यह ऊपर दिए गए dnf पैकेज (साथ ही grub2-efi-x64-modules, systemd-boot-unsigned, efivar-devel, dracut) स्थापित करता है और पिन किए गए busybox udhcpc और wget बाइनरी प्राप्त करता है।

बिल्ड

बिल्ड होस्ट पर:

./install-dependencies.sh
make

सादा make uki.efi, BOOTX64.EFI और deploy लिखता है। यह ESP, /var/lib/systemd/boot या NVRAM नहीं लिखता। ट्रेलर मैजिक और SOURCE_DATE_EPOCH ARCHITECTURE.md में हैं।

डिप्लॉय

शिप किए गए deploy ELF को टारगेट पर कॉपी करें। कोई कंपाइलर नहीं। uki.efi और BOOTX64.EFI पहले से ही ट्रेलर के अंदर हैं।

scp deploy user@target-host:~/

सह-स्थित (colocated) AL2023 इंस्टेंस पर कॉपी वैकल्पिक है; बिल्ड ट्री से ./deploy चलाएँ।

अगले रीबूट पर, फ़र्मवेयर Boot0002 ESP PE लोड करता है, PE UKI को चेनलोड करता है, पेलोड चलता है, फिर kexec स्टॉक BLS कर्नेल शुरू करता है (ARCHITECTURE.md)। यदि deploy EFI variables are not supported on this system प्रिंट करता है, तो यह बूट BIOS है; आवश्यकताएँ देखें।

उपयोग

deploy के लिए रूट आवश्यक है। बिना किसी तर्क के यह ट्रेलर ऑफसेट और NVRAM डंप करता है और कुछ नहीं लिखता। -y इमेज और NVRAM स्थापित करता है, फिर इस निष्पादन योग्य को वाइप और अनलिंक करता है। कोई अन्य तर्क उपयोग प्रिंट करता है।

./deploy          # dump only: trailer offsets and NVRAM; no writes
./deploy -y       # plant, then wipe and unlink this binary
reboot

सफल -y रन पर प्रक्रिया अपने स्वयं के निष्पादन योग्य (/dev/urandom, truncate, unlink) के वाइप को अपने बाहर निकलने के बाद शेड्यूल करती है, इसलिए ls deploy विफल होना चाहिए। स्थापित UKI और बूटकिट GRUB इमेज बनी रहती है।

-y /var/lib/systemd/boot/uki.efi (root:root, 0500) और /boot/efi/EFI/BOOT/.BOOTX64.EFI (root:root, VFAT पर बेस्ट-एफर्ट 0700) लिखता है, फिर NVRAM Boot0002 बनाता है और उसे BootOrder पर पहले रखता है। स्टॉक BOOTX64.EFI Boot0001 बना रहता है।

सत्यापन

बिल्ड होस्ट

make

यह तीनों उत्पादों को बनाता है। कोई इन-ट्री टेस्ट सूट नहीं है। एक AL2023 इंस्टेंस पर सह-स्थित make जो बाद में ./deploy -y चलाएगा, स्वच्छ-रनटाइम प्रमाण नहीं है।

रनटाइम होस्ट

रीबूट के बाद आपको स्टेज-2 स्टॉक यूज़रस्पेस में होना चाहिए: कर्नेल, /proc/cmdline, और initrd पथ जो एक सामान्य BLS बूट उपयोग करता।

cat /root/HELLO.TXT
# expect: stage-1 cmdline with BOOTKIT_MARKER, 98-payload.sh banner,
#         pre-OS network breadcrumbs (NIC up, DHCP/udhcpc, default route),
#         wget / external_ip=... / result, then
#         99-kexec-stock: resolve=bls:..., kexec -l ok, kexec -e

grep BOOTKIT_MARKER /proc/cmdline || echo "no marker (stage-2 ok)"
# expect: no marker

dmesg | head -3
# expect: stock-style cmdline (BLS options), not BOOTKIT_MARKER=1

uname -r
# expect: the dnf/grubby default on disk

फ़ाइलें

deploy -y नीचे दिए गए डिफ़ॉल्ट लिखता है। NVRAM BootOrder और Boot0002 फ़र्मवेयर स्थिति हैं, फ़ाइलें नहीं।

यदि आप ESP PE नाम या UKI पथ बदलते हैं, तो mk-bootx64-efi.sh, deploy.c और NVRAM प्रविष्टि को सिंक में रखें (ARCHITECTURE.md देखें)।

सीमाएँ

• ट्री Amazon Linux 2023 (amzn / 2023) और EC2-आकार के Boot0001 पर गेट करता है। एम्बेडेड PE जाँचों के लिए AMD64 (0x8664) आवश्यक है। ARM64 / Graviton (अभी?) समर्थित नहीं है।
• सिक्योर बूट दायरे से बाहर है। स्टॉक EC2 में यह बंद है। इमेज अहस्ताक्षरित हैं।
• यह केवल पर्सिस्टेंस/बूटकिट है। UKI और ESP PE पूर्ण डिस्क वॉक के लिए दृश्यमान रहते हैं। किसी रूटकिट LKM द्वारा डायरेक्ट्री लिस्टिंग या open को फ़िल्टर करना इस प्रोजेक्ट के दायरे से बाहर है।
• deploy सेल्फ-वाइप बेस्ट-एफर्ट है। यह SSD या NVMe पर सुरक्षित मिटाना नहीं है। पूर्ण वेपनाइज़ेशन और उच्च स्तर के OPSEC के लिए एक कस्टम deploy की अनुशंसा की जाती है।
• c5a.xlarge और t3.nano पर विकसित और परीक्षण किया गया।

यह भी देखें

• ARCHITECTURE.md