Windows 11 में मेमरी डंप से BitLocker बायपास करना

 (noinitrd.github.io)
2 पॉइंट द्वारा GN⁺ 2025-01-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Windows 11 24H2 वातावरण में Memory-Dump-UEFI से RAM डंप करके पूर्ण वॉल्यूम एन्क्रिप्शन कुंजी FVEK निकाली जाती है और BitLocker-सुरक्षित वॉल्यूम तक पहुंच का प्रदर्शन किया गया है
  • यदि हमलावर को डिवाइस तक भौतिक पहुंच मिल जाए, तो वह रीस्टार्ट के तुरंत बाद RAM में बचे हुए keys को निशाना बना सकता है, लेकिन बिजली कटे रहने का समय बढ़ने पर RAM content corruption का जोखिम बढ़ जाता है
  • डेमो में मदरबोर्ड के reset pins को शॉर्ट करके बिना power loss के रीस्टार्ट किया गया, और Secure Boot बायपास के मामलों को डेमो के दायरे से बाहर रखा गया
  • Windows 11 डंप में, पुराने Windows 7 के FVEc और Windows 8.1/10 के Cngb की जगह dFVE और None टैग के अंतर्गत FVEK मिला
  • Microsoft SymCryptSessionDestroy जैसे functions से keys नष्ट करने की कोशिश करता है, फिर भी keys heap में बची रह सकती हैं; इसलिए BitLocker implementation के विश्लेषण के लिए kernel-level debugging सबसे सीधा तरीका है

Windows 11 BitLocker बायपास डेमो का दायरा

  • लक्ष्य Windows 11 version 24H2 है, और तरीका BitLocker की पूर्ण वॉल्यूम एन्क्रिप्शन कुंजी FVEK को मेमरी से निकालने पर आधारित है
  • RAM content डंप करने के लिए UEFI application Memory-Dump-UEFI का उपयोग किया गया
  • मुख्य पूर्वधारणा यह है कि हमलावर के पास डिवाइस तक भौतिक पहुंच हो

RAM डंप के सफल होने की शर्तें

  • हाल ही में चल रहे Windows instance की RAM में FVEK जैसी संवेदनशील जानकारी बची हो सकती है
  • बिजली कटने पर RAM content जल्दी खराब होने लगती है, इसलिए रीस्टार्ट प्रक्रिया में कंप्यूटर के पूरी तरह बंद रहने का समय न्यूनतम रखना चाहिए
  • RAM corruption कम करने के तरीकों में physical cooling या external power supply बनाए रखना शामिल है; डेमो में मदरबोर्ड के reset pins को शॉर्ट करके बिना power loss के रीस्टार्ट किया गया
  • Secure Boot डिवाइस स्टार्टअप पर चल सकने वाली चीजों को सीमित करने वाला सुरक्षा मानक है, लेकिन shim आदि के जरिए इसके बायपास के उदाहरण मौजूद हैं; इस डेमो में इसे विस्तार से नहीं लिया गया

बूट USB की तैयारी और डंप बनाना

  • बूट USB में लक्ष्य सिस्टम की RAM क्षमता से बड़ा storage device होना चाहिए
  • flashimage.sh script बूटेबल application तैयार करने की प्रक्रिया को सरल बनाती है
  • बूट application बनाने और उपयोग करने की प्रक्रिया MemoryDumpUEFI में दी गई है
  • FVEK मिलने की संभावना सबसे अधिक तब थी जब Windows लोड हो रहा हो लेकिन login screen आने से पहले रीस्टार्ट किया जाए
  • USB डिवाइस से तुरंत Memory-Dump-UEFI में बूट करने के बाद UEFI shell में app.efi चलाया जाता है
    • इसे चलाने के तरीके के लिए application की README में अतिरिक्त steps हैं
    • डंप में लगने वाला समय RAM क्षमता और USB डिवाइस की गति पर निर्भर करता है
    • गलत drive पर लिखने से बचने के लिए दूसरे USB storage devices अलग कर देना बेहतर है

डंप फाइल प्रोसेसिंग और खोज उपकरण

  • Memory-Dump-UEFI कई dump files बना सकता है
  • UEFI specification के अनुसार FAT32 filesystem का उपयोग करना पड़ता है, और FAT32 में 4GB file size limit होती है
  • tools directory का concatDumps कई dumps को समय क्रम में जोड़कर एक बनाता है
  • डंप उस समय मेमरी में मौजूद raw data होता है, इसलिए xxd जैसे tools से उसे आसानी से देखा जा सकता है
  • searchMem dump के भीतर hex pattern खोजता है और मिले हुए स्थान के offset पर जाने देता है

pool tag और FVEK का स्थान

  • pool tag Windows kernel memory pool की पहचान करने वाला 4-अक्षरी identifier है
  • Windows kernel द्वारा allocate किए गए memory pools संवेदनशील जानकारी खोजने के लिए उपयोगी स्थान हो सकते हैं
  • pooltag.txt में pool tags की सूची और उनके उद्देश्यों की जानकारी होती है
  • पुराने Windows versions में BitLocker key का स्थान अलग था
    • Windows 7 में fvevol.sys के encryption allocation से जुड़े FVEc pool tag से key recovery संभव थी
    • Windows 8.1 और Windows 10 में ksecdd.sys module से जुड़े Cngb tag memory pool में key मिल सकती थी
  • Windows 11 dump में FVEc और Cngb में key नहीं मिली; इसकी जगह दो स्थानों पर FVEK मिला
    • पहला स्थान dFVE pool tag के अंतर्गत था, जो dumpfve.sys द्वारा allocate की गई memory को दर्शाता है
    • dumpfve.sys BitLocker drive encryption के full volume encryption crash dump filter से संबंधित है
    • dFVE वह स्थान था जहां key सबसे आसान और लगातार मिली
    • यहां key से पहले encryption type दिखाने वाला 0x0480 लगा था, जो डेमो वातावरण में XTS-AES-128 को दर्शाता है
    • दूसरा स्थान None tag के अंतर्गत था, जो ExAllocatePool call से संबंधित है
    • यहां key का पहला आधा भाग दो बार और दूसरा आधा भाग एक बार दिखाई दिया

FVEK से BitLocker वॉल्यूम तक पहुंचना

  • प्राप्त key के आगे उपयोग किए जा रहे encryption algorithm का मान जोड़ना पड़ता है
  • उदाहरण में key के आगे algorithm value 0x8004 को little endian रूप 0480 में जोड़ा गया
  • इस तरह बने मान को फाइल में सेव करके output.fvek के रूप में उपयोग किया जा सकता है
  • dislocker toolset आवश्यक algorithm और value की जांच करने तथा BitLocker-सुरक्षित partition को unlock करने के लिए अनुशंसित है
  • यदि प्रक्रिया सही हो, तो output.fvek से BitLocker-सुरक्षित वॉल्यूम के data तक पहुंचा जा सकता है

BitLocker implementation का विश्लेषण और heap में बची keys

  • BitLocker implementation को समझने का सबसे सीधा तरीका windbg का उपयोग कर kernel-level debugging करना है
  • kernel debugging virtual machine या crossed over USB 3.0 A/A cable के जरिए अपेक्षाकृत आसानी से की जा सकती है
  • Windows boot process को step-by-step देखते हुए BitLocker के व्यवहार का निरीक्षण करना key खोजने में मददगार रहा
  • Microsoft SymCryptSessionDestroy जैसे functions से keys मिटाने की कोशिश करता है, लेकिन keys heap में बची रह सकती हैं, इसलिए सभी keys पूरी तरह हट नहीं पातीं

संदर्भ लिंक

  • recovering-bitlocker-keys-on-windows-8-1-and-10: Windows 8.1 और Windows 10 में BitLocker key recovery से संबंधित सामग्री
  • dislocker: BitLocker वॉल्यूम तक पहुंचने में उपयोग किया गया toolset
  • SymCrypt: Microsoft cryptography library
  • libbde: BitLocker Drive Encryption से संबंधित library
  • pooltag.txt: Windows pool tags की सूची
  • An Introduction to Pool Tags: pool tags पर Microsoft की परिचयात्मक सामग्री

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-01-01
Hacker News की राय

  • मुझे लगता है कि BitLocker का सबसे बड़ा फायदा तब है जब TPM(PCR 7+11)+PIN इस्तेमाल किया जाए
    PIN के बिना FVEK पढ़ा नहीं जा सकना चाहिए, इसलिए यह इस हमले को कम कर सकता है, और अगर BitLocker सही तरीके से implement किया गया है तो PIN बहुत बार गलत डालने पर TPM dictionary attack lockout mode में चला जाता है
    मैं कई महीनों से Linux पर भी यही configuration करने की कोशिश कर रहा हूं, लेकिन systemd-cryptsetup/cryptenroll LUKS के लिए हैं, और मेरी स्थिति यह है कि धीमे embedded eMMC पर fscrypt से कुछ संवेदनशील directories (secure boot keys और /home) को encrypt करना चाहता हूं
    बुनियादी चीज़ों से आगे बढ़ते ही TPM coding बेहद कठिन लगती है: PCR 7 से bind करना, kernel/init/cmdline update हर बार बदलने वाले PCR 11 से bind करना, AuthValue नहीं बल्कि PIN इस्तेमाल करना, login पर DA lockout counter reset करने के लिए भी वही authorization policy इस्तेमाल करना, साथ में manual reset के लिए लंबा password/AuthValue रखना, और systemd-stub द्वारा दिए गए PCR 11 signatures और public key से भी match कराना
    basic TPM guides के अलावा material लगभग नहीं है, इसलिए अगर कोई expert हो तो मदद लेना चाहूंगा। यह personal project है, लेकिन कभी पूरा हुआ तो इसे लेख के रूप में लिखने का इरादा है

    • LUKS में कई key slots होते हैं, इसलिए मुझे याद है कि एक slot को TPM unlock के लिए और दूसरे slot को long password recovery के लिए इस्तेमाल किया जा सकता था
      recovery mechanism के तौर पर इस तरीके पर विचार किया जा सकता है
      hobby के तौर पर open source TPM से छेड़छाड़ करने वाले लोग कम हैं, इसकी एक वजह यह है कि ऐसी जरूरतों को बहुत आसान तरीके से हल करने वाले alternatives बहुत हैं
      अगर important encryption keys को hardware से bind करना है तो Yubikey खरीद सकते हैं, और laptop disk encryption password झंझट लगता है तो पूरी तरह shutdown करने के बजाय lid बंद करते समय standby mode इस्तेमाल कर सकते हैं
      login password असुविधाजनक है तो fingerprint reader या biometric authentication Yubikey हैं, और अगर unmanned kiosk या school computer lab की तरह password के बिना boot करना हो तो उसे मजबूत metal box में रखकर दीवार से chain से बांध सकते हैं
      अगर datacenter server को unattended boot करना है तो उसे भरोसेमंद physical security वाले datacenter में ले जाएं, और फिर भी चिंता हो तो Dropbear या Tang से ऐसा करें कि सही network में होने पर ही boot हो
      अगर homelab hobby के तौर पर TPM से खेल रहे हैं तो सचमुच यह जांच लेना अच्छा है कि TPM पर काम करना मजेदार है या नहीं, और शायद आपको पता चलेगा कि ऐसा नहीं है
    • Windows, भले ही TPM पहली बार FVEK हासिल करने के लिए PIN मांगे, आखिरकार FVEK को RAM में रखेगा
      ऐसा न हो तो हर बार disk block decrypt करते समय PIN डालना पड़ेगा, है ना? हर disk operation पर TPM call करने का performance impact भी बड़ा होगा
      यह attack RAM से key पढ़ता है, इसलिए समझ नहीं आता कि TPM PIN कैसे mitigation बनता है
    • मुझे लगता है split-key encryption या encrypted secret key इस्तेमाल करना बेहतर हो सकता है
      अगर boot से पहले password डालना पड़े, और drive खोलने के लिए उस password को TPM key के साथ combine करना पड़े, तो बाद में TPM key मिल जाने वाली स्थिति में मदद मिलेगी
      हालांकि इस attack के खिलाफ कौन सा उपाय कितना मदद करेगा, यह कहना मुश्किल है। OS को drive read/write access बनाए रखने के लिए key कहीं न कहीं रखनी ही पड़ेगी, इसलिए key खोजने की location बदलने भर से ज्यादातर scenarios में इस तरह RAM data recovery संभव होगी
      मुझे याद है कि Apple devices में key secure enclave से बाहर नहीं आती, इसलिए लगता है कि वे ऐसे attacks के प्रति vulnerable नहीं होंगे। TPM 3.0 को उस दिशा के काफी करीब जाने की जरूरत दिखती है
    • लगता है कि BIOS power-on password भी काम करना चाहिए। उसके बिना system उस point तक नहीं पहुंच पाएगा जहां TPM FVEK को unlock करता है
      ThinkPad पर power-on password के बजाय fingerprint इस्तेमाल किया जा सकता है, और चोर के लिए device को लगभग बेकार बना सकता है, इसलिए मैं BitLocker PIN की तुलना में इस configuration को पसंद करता हूं
      बेशक power-on password और fingerprint authentication भी TPM जितने ही मजबूत हैं, लेकिन BitLocker TPM+PIN भी ऐसा ही नहीं है क्या
    • TPM कुछ हद तक honeypot जैसा लगता है
      successful open source encryption software के बाद TPM की ओर जाने का रुझान अजीब लगता है। ऐसा लगता है जैसे बड़ी कंपनियां कह रही हों कि हमारे पास super-secure storage है, इसलिए चिंता या सवाल मत करो
      शक होता है कि कोई backdoor जरूर होगा जिससे intelligence agencies सभी PIN और passwords download करके data access कर सकें

  • BitLocker के security model को मूल रूप से ठीक से समझ नहीं पा रहा हूँ
    ज़्यादातर installations में power button दबाने पर Windows में boot होता दिखता है
    तो अगर कोई encrypted hard drive वाला device चुरा ले, तो क्या उसे बस उसे on करना होगा? ऐसा तो नहीं हो सकता, लेकिन साथ ही यह भी समझ नहीं आता कि यह specific attack कैसे रोका जाता है
    शायद मानना पड़ेगा कि SPI bus traffic encrypted होता है, इसलिए key को इस तरह dump नहीं किया जा सकता, लेकिन फिर भी ऐसा लगता है कि machine key काफ़ी आसानी से दे देती है
    LUKS में कम-से-कम drive unlock करने के लिए password prompt होता है

    • SPI bus traffic encrypted नहीं होता
      अजीब बात है कि Microsoft TPM parameter encryption इस्तेमाल नहीं करता, इसलिए हर 1–2 साल में कोई security researcher TPM sniffing device बनाकर demo कर देता है
      LUKS भी configuration पर निर्भर करता है। Linux को भी यहाँ Windows की तरह configure किया जा सकता है, और मेरे home video security server को भी चुपचाप reboot होना चाहिए, इसलिए मैंने उसे ऐसे ही set किया है। मुझे पता है कि यह warm/cold boot attacks और software attack surface के लिए vulnerable है, लेकिन अगर कोई सिर्फ drive निकालकर ले जाए तो safe है
      Windows को भी password माँगने या PIN-authenticated TPM sealing key इस्तेमाल करने के लिए configure किया जा सकता है
      Parameter encryption और bus sniffing वाली समस्या छोड़ दें, तो BitLocker boundary को “कोई भी drive पढ़ सकता है” से “memory contents पाने के लिए platform-level attack करना होगा या login screen पर चल रही services hack करनी होंगी” तक ले जाता है
      randomly recycled hard drives से financial data चुराने जैसी स्थितियों को यह बहुत अच्छी तरह रोकता है, इसलिए असल में यह काफी अच्छा security improvement है
    • चोरी किए गए device को on करने पर आप सिर्फ login screen तक पहुँचते हैं, और password या biometric authentication के बिना उससे आगे नहीं जा सकते
      इसके लिए remote code execution vulnerability या पुराने vulnerable Windows bootloader से boot करने जैसा bypass चाहिए। Drive locked है, इसलिए आम “software keyboard को cmd.exe से बदल देना” वाला bypass नहीं चलेगा
      BitLocker न हो तो Windows drive को दूसरे PC में लगाकर सारी files देख सकते हैं। BitLocker हो तो vulnerable Microsoft software, vulnerabilities, dumped memory जैसी चीज़ों से जूझना पड़ता है, और वह भी हमेशा काम नहीं करता
      अगर BitLocker को TPM+PIN mode में set करें, तो TPM खोलने के लिए password नहीं होता, इसलिए वह भी नहीं कर सकते। BitLocker को password-only mode में भी रखा जा सकता है, लेकिन वह brute-force के लिए कहीं ज़्यादा vulnerable है
      LUKS भी ऐसा ही है; आजकल ज़्यादातर Linux distributions TPM और TPM+PIN support करते हैं
    • सही है, लेकिन intention यह है कि login screen (winlogon) पर, अगर आपके पास उस computer के account credentials नहीं हैं या biometric enrollment नहीं है, तो असल में करने को बहुत कम होता है
      Safe mode में reboot करने या किसी दूसरे OS, firmware update utility आदि में reboot करने की कोशिश करें तो BitLocker recovery key डालनी पड़ती है
      Fingerprint sensor या face recognition webcam को “hack” करने के मामले में यह internally कैसे काम करता है, यह मुझे ठीक से नहीं पता
    • BitLocker को PIN+TPM के साथ इस्तेमाल करने का मुख्य उद्देश्य powered-off computer या drive को practically ईंट बना देना है
      यह मानना पड़ता है कि TPM में key extraction vulnerability नहीं है
      मुख्य बात powered-off state है
      General-purpose drive encryption में TPM वास्तविक bulk data decrypt नहीं करता, क्योंकि वह बहुत slow है; आखिर में OS के पास extract की जा सकने वाली key होती है
    • BitLocker volume के कई protectors हो सकते हैं, और key file, passphrase, PIN, TPM storage इस्तेमाल कर सकता है: https://learn.microsoft.com/en-us/windows-server/administrat...
      Pro edition में group policy के जरिए boot के समय interactive step require किया जा सकता है। यह TPM के बिना भी काम करता है, और इस case में हर startup पर password पूछता है

  • इसे https://trustedcomputinggroup.org/resource/pc-client-work-gr... से पूरी तरह रोका जा सकता है
    अगर यह enabled हो, तो जब OS clean shutdown नहीं कर पाया और encryption key मिटाने का मौका नहीं मिला, अगली boot से पहले firmware रुककर RAM clear करता है
    सोच रहा हूँ कि Windows इसे इस्तेमाल नहीं करता, या test किया गया system इसे implement नहीं करता था

    • Windows के इस feature को इस्तेमाल करने की जानकारी है: https://learn.microsoft.com/en-us/windows/security/operating...
      इसमें लिखा है कि “BitLocker keys को memory में extract करने से पहले TCG Reset Attack Mitigation, जिसे MOR bit (Memory Overwrite Request) भी कहा जाता है, इस्तेमाल करता है”
      हालांकि ज़्यादातर platform implementations पर मुझे बिल्कुल भरोसा नहीं है। मैंने किसी भी तरह से सही implementation के करीब कोई UEFI platform नहीं देखा
      यह जानना दिलचस्प होगा कि इस researcher ने कौन-सा platform इस्तेमाल किया, और क्या वह platform MOR bit support का दावा करता है
    • वह mitigation काफ़ी कच्ची है, क्योंकि RAM overwrite के दौरान भी interfere किया जा सकता है
      बस देखिए कि Team Tweezers ने original Wii को कैसे attack किया था
      असली mitigation modern CPUs की memory encryption feature है। यह die के अंदर होता है, इसलिए tweezers वहाँ नहीं पहुँचते, और सिर्फ key मिटानी होती है, इसलिए deletion instant होता है; power cycle survive कर भी जाए तो भी interfere करना बहुत मुश्किल है
    • फिर भी यह पूरे RAM module को निकालकर offline dump करने से नहीं रोकता
      Ideally key केवल CPU के SRAM cache के अंदर ही रहनी चाहिए और CPU die के बाहर कभी नहीं जानी चाहिए

  • लेख लिखने वाला मैं ही हूँ। अगर सवाल हों तो इस account पर message भेज सकते हैं
    इस पर काम करना सच में मज़ेदार था और इतने interest के लिए धन्यवाद

  • Windows 11 BitLocker bypass से जुड़ी 38C3 presentation: https://media.ccc.de/v/38c3-windows-bitlocker-screwed-withou...

  • यह बात काफी अच्छी तरह जानी जाती है कि BitLocker सिर्फ बंद कंप्यूटर की ही ठीक से सुरक्षा करता है, और वह भी केवल तब जब BitLocker को boot password मांगने के लिए सेट किया गया हो
    [0] https://en.wikipedia.org/wiki/BitLocker#TPM_alone_is_not_eno...

  • Windows में memory compression के साथ प्रस्तावित memory encryption विकल्प मौजूद है
    Intel और AMD दोनों इस feature को CPU में जोड़ने पर काम कर रहे हैं
    हालांकि इसका target लैपटॉप नहीं, बल्कि कई virtual machines चलाने वाले servers लगते हैं

    • Microsoft, software के खास हिस्सों की सुरक्षा के लिए “enclaves” चलाने की क्षमता सहित, virtualization-based security की ओर लगातार बढ़ रहा है: https://learn.microsoft.com/en-us/windows/win32/trusted-exec...
      जल्द ही encrypted “virtual machine” को ऐसे secret values store करने के साधन के रूप में इस्तेमाल किया जाए, तो हैरानी नहीं होगी। इसके लिए जरूरत है consumer platforms पर व्यापक रूप से सामान्य हो चुके hardware support की
      हालांकि पुराने CPU side-channel attacks ने दिखाया है कि encrypted memory पर भी हमला किया जा सकता है (https://www.usenix.org/conference/usenixsecurity21/presentat...). जब CPU सामान्य operation के लिए memory को decrypt करता है, तो वे cache को निशाना बनाते हैं
      यह memory dump को बेअसर करने में मदद करेगा, लेकिन encrypted RAM memory से keys dump करने की समस्या को खत्म नहीं कर पाएगी। खासकर धैर्यवान या बेहद कुशल attackers के खिलाफ तो और भी नहीं
    • Intel फिलहाल Total Memory Encryption feature के रूप में यह उपलब्ध कराता है। Windows ecosystem में, ठीक ही है, इसका निशाना virtual machines की तरफ है
      https://techcommunity.microsoft.com/blog/windowsosplatform/m...
      memory compression काफी पहले से मौजूद है, कम से कम Windows 10 RTM से। सभी प्रमुख operating systems ने यह feature implement किया है, लेकिन इसका security से संबंध नहीं है

  • संबंधित लेख: Lenovo laptop पर सस्ते logic analyzer से BitLocker bypass करना
    https://news.ycombinator.com/item?id=37249623

  • ऐसे हमलों में जो target machine के memory dump को पढ़ने पर निर्भर करते हैं, अगर physical access हो तो RAM में आने-जाने वाले data को copy या modify करने वाला interposer device कितना व्यावहारिक होगा, यह सोचने वाली बात है
    पुराने Gameboy के लिए “Action Replay” जैसा device याद आता है, जो game cartridge से system में load या execute होने वाली memory को modify करके cheats संभव बनाता था। cartridge को Action Replay में लगाते थे, और Action Replay को Gameboy में
    क्या RAM और motherboard के बीच भी ऐसा ही कुछ किया जा सकता है? RAM को device में लगाना, उस device को motherboard में लगाना, फिर memory reads/writes को observe करके किसी भी समय memory state capture करना
    इससे manually power off करने और जरूरी data के बचा रहने की उम्मीद करने की झंझट से बचा जा सकेगा
    मैं electrical engineer नहीं हूं, इसलिए यह प्रस्ताव पूरी तरह असंभव भी हो सकता है। physical space और bandwidth constraints निश्चित रूप से बड़े लगते हैं, लेकिन क्या यह संभव है?

    • सैद्धांतिक रूप से संभव है। असल में, DDR link setup करते समय memory controller और RAM के बीच काफी negotiation की जरूरत होती है, और वही timing बनाए रखते हुए data dump करने वाली स्थिति बनाना आसान नहीं है
      इसके लिए off-the-shelf solution आने की उम्मीद करना मुश्किल है
    • आधुनिक AMD/Intel CPUs transparent full memory encryption support करते हैं, इसलिए ऐसा interposer केवल encrypted RAM data ही देखेगा

  • यह बात कम लोग जानते हैं कि हाल के वर्षों में आए Intel/AMD CPUs transparent full memory encryption support करते हैं
    RAM contents को CPU memory controller के अंदर रखी और reset के समय generate होने वाली random key से encrypt किया जाता है
    आमतौर पर BIOS में यह off रहता है, क्योंकि memory performance में थोड़ी गिरावट (0.1%~1%) आती है
    लेकिन यह attack को पूरी तरह रोक सकता है

    • मेरी समझ के अनुसार, AMD में इस feature को SME(Secure Memory Encryption) और Intel में TME-MK(Total Memory Encryption-Multi Key) कहा जाता है