📕 🖼️ 💪 "घातक रूप से मूल" ग्राफिक्स सबसिस्टम पर ले जाया गया 🔧 🥁 🎦

जिसे आमतौर पर "ग्राफिक्स इन द कर्नेल" कहा जाता है, आमतौर पर win32k को संदर्भित करता है। Win32k.sys ग्राफिक्स सबसिस्टम का मूल है। अन्य सभी सबसिस्टमों के आरंभ के दौरान उपयोगकर्ता प्रक्रिया smss..exe द्वारा लोड की जाती है। "किमीोड" सबसिस्टम के लिए निष्पादन योग्य छवि का मार्ग यहां पंजीकृत है:

यह कैसे होता है?

यहां (स्क्रीनशॉट के नीचे ट्रेस स्टैक पर), यह स्पष्ट रूप से दिखाई देता है कि smss उपयोगकर्ता मोड की win32k बूट प्रक्रिया (जो, अन्य चीजों के अलावा, पेजिंग फ़ाइलों, रजिस्ट्री, पर्यावरण चर को इनिशियलाइज़ करती है, एक मेमोरी डंप को बचाता है, अगर पहले बगस्किट था, तो wininit के साथ सेवा शुरू करता है। नियंत्रण प्रबंधक और स्थानीय सुरक्षा प्राधिकरण सबसिस्टम, लॉगऑन सत्र इत्यादि बनाता है।), और पहली चीज़ जो win32k करता है वह कर्नेल के साथ "कनेक्शन स्थापित करना" है। और यहाँ क्यों है: win32k कर्नेल की तुलना में उच्च स्तर पर है, इसलिए कर्नेल पर निर्भरता नहीं हो सकती है ("निर्भरता" इस मामले में क्लासिक "कारण बदलने का कारण है") (विशिष्ट कार्यान्वयन) win32k पर, लेकिन कर्नेल और win32k दोनों हो सकते हैं इंटरफ़ेस पर निर्भर सुरक्षित रूप से। ऐसा इंटरफ़ेस KWIN32_CALLOUTS_FPNS संरचना है और कर्नेल में इस इंटरफ़ेस के विशिष्ट कार्यान्वयन को पंजीकृत करने के लिए फ़ंक्शन PsEstablishWin32Callouts है।

इसके अलावा, win32k ऑब्जेक्ट मैनेजर द्वारा प्रदान किए गए सामान्य-उद्देश्य इंटरफेस के माध्यम से कई प्रकार की वस्तुओं (विशेष रूप से, डेस्कटॉप और विंडोस्टेशन) को पंजीकृत करता है।

इस प्रकार, कर्नेल को win32k पर कोई निर्भरता नहीं है। इसके अलावा, NT4 से पहले, सभी उपयोगकर्ता / gdi API को csrs में संसाधित किया गया था और निश्चित रूप से, धीमा कर दिया गया था। NT4 के साथ शुरू, प्रदर्शन में सुधार के लिए कर्नेल में उपयोगकर्ता / gdi प्राइमेटिक्स के भाग को पोर्ट किया गया है।

सामान्य तौर पर, win32k को पूरी तरह से हटाया जा सकता है, आप इसे अपने कर्नेल भाग से बदल सकते हैं, या आप उपयोगकर्ता मोड में पूरी तरह से सब कुछ लागू कर सकते हैं (उदाहरण के लिए, कर्नेल के साथ संवाद करने के लिए ioctls), लेकिन यह धीमा हो जाएगा। एकमात्र कारण यह नहीं किया जाता है क्योंकि इसकी आवश्यकता नहीं है। आप दूसरे तरीके से लिख सकते हैं - हां, लिखना बेहतर है - शायद ही। वैसे, पुनर्लेखन के लिए पुनर्लेखन एक अच्छा विचार नहीं है।

अभ्यास सच्चाई की कसौटी है या "घुटने पर मिनविन"

गलतफहमी को खत्म करने के लिए, मैं तुरंत कहना चाहता हूं: मैं जो करूंगा वह मिनविन नहीं है । यह कम से कम नहीं है क्योंकि वास्तविक मिनविन में उपयोगकर्ता (उपयोगकर्ता मोड) बायनेरिज़ का एक न्यूनतम सेट होता है, लेकिन मैं पूरी तरह से लोड किए गए कर्नेल को प्रदर्शित करने जा रहा हूं (एक और अंतर यह है कि मिनविन में ड्राइवरों का न्यूनतम सेट शामिल है, लेकिन मेरे ड्राइवरों का सेट नियमित लोडिंग की तुलना में नहीं है। ) किसी भी उपयोगकर्ता मोड के बिना (ठीक है, एक प्रक्रिया और एक dll वहाँ अभी भी है, लेकिन आपको कम से कम किसी तरह उपयोगकर्ता को दिखाने की ज़रूरत है कि कुछ हो रहा है)। प्रतिबिंब का एक अतिरिक्त कारण यह तथ्य हो सकता है कि असली मिनविन विंडोज 7 कोड को "बंडल" करने के काम के सिलसिले में दिखाई दिया था, वही चीज जो मैं सिद्धांत रूप में करूंगा वह XP पर भी संभव है और NT3.51 पर भी

इसलिए, यदि आप ध्यान से पढ़ते हैं कि पिछले भाग में क्या लिखा गया है, तो आप अनुमान लगा सकते हैं कि हमें smss को एक के साथ बदलने की आवश्यकता है जो सबसिस्टम को इनिशियलाइज़ नहीं करता है, लेकिन फिर भी कम या ज्यादा इंटरएक्टिव रहता है। smss.exe एक साधारण देशी प्रक्रिया है (लगभग, एक मूल अनुप्रयोग एक अनुप्रयोग है जो केवल ntdll.dll से लिंक करता है और तदनुसार केवल काम करने के लिए मूल निवासी API का उपयोग करता है)। मेरे लिए सौभाग्य से, एक पूर्व रिएक्टोस मुख्य डेवलपर, एलेक्स इओन्सकु, पहले ही (लंबे समय से बंद) स्मॉलक्रानल प्रोजेक्ट के हिस्से के समान एक आवेदन लिख चुके हैं। यह एप्लिकेशन amd64 के तहत नहीं बनाया गया है, नवीनतम WDK पर नहीं बनाया गया है, इसमें कई बग हैं, लेकिन आम तौर पर काम करता है। निम्न छवि को संग्रहकर्ता द्वारा खोला जा सकता है - इसमें छोटे अनुप्रयोग नेटिव के स्रोत और संकलित am6464 बाइनरी शामिल हैं:

कृपया मुझे माफ़ कर दें, लेकिन मैं समाप्त की गई छवि को समाप्त नहीं कर सकता क्योंकि यह गैरकानूनी है, इसलिए मैं वह कोड पोस्ट करता हूं जो स्थापना छवि से vhd-image को एकत्र कर सकता है।

निम्न कोड Win7 पर केवल निष्पादित किया जा सकता है। नाम के तहत एक अस्थायी निर्देशिका के लिए इसे कहीं और सहेजें, उदाहरण के लिए minwin.ps1, इसके आगे install.wim रखें (विंडोज स्रोतों के एन-यू इंस्टॉलेशन डिस्क से (\ स्रोत निर्देशिका में स्थित है) (यह महत्वपूर्ण है - इस स्थानीयकरण के लिए आवश्यक केवल एनएलएस फाइलें कॉपी की जाती हैं), इस निर्देशिका के ऊपर दी गई तस्वीर से native.exe फ़ाइल को सहेजें, उन्नत कंसोल में इसी निर्देशिका पर जाएँ और निम्न कार्य करें:

powershell -executionpolicy bypass .\minwin.ps1

संक्षिप्तता के लिए:

1. एक निर्देशिका के आगे निम्नलिखित फाइलें होनी चाहिए: minwin.ps1, install.wim और native.exe

2. आपको उपरोक्त फ़ाइलों वाली निर्देशिका में वर्तमान निर्देशिका को बदलने के बाद ही minwin.ps1 चलाना होगा

अस्वीकरण: आप अपने जोखिम पर निम्नलिखित में से सभी करते हैं। टीमें काफी स्पष्ट हैं और उन्हें कोई नुकसान नहीं पहुंचाना चाहिए, लेकिन यह "घुटने की ऊँची" रचनात्मकता है, इसलिए यह किसी भी स्थिति में काम करने के लिए बाध्य नहीं है। यदि आप EVERY कमांड के अर्थ को नहीं समझते हैं, तो इस स्क्रिप्ट को निष्पादित न करें (विशेषकर जब से निष्पादन एक उच्च उपयोगकर्ता के तहत निष्पादित किया जाना चाहिए)। यदि नहीं, तो नीचे एक तस्वीर है कि यह आखिर कैसे दिखता है। एक सरलीकृत संस्करण में, आप केवल native.exe का नाम बदलकर smss..exe कर सकते हैं, पहले से लोड की गई वर्चुअल मशीन में मौजूदा smss.exe पर कॉपी कर सकते हैं (कोई भी x64 Windows काम करेगा - XP से 7 तक) और रिबूट।

स्क्रिप्ट ही:

 $vhdName = "disk.vhd" $wimName = "install.wim" $vhdDisk = "V" $wimMountName = "MountedWim" md $wimMountName dism /mount-wim /wimfile:$wimName /index:1 /mountdir:$wimMountName #del $vhdName @" create vdisk file=$pwd\$vhdName type=expandable maximum=128 select vdisk file=$pwd\$vhdName attach vdisk create partition primary format fs=ntfs quick assign letter=$vhdDisk active "@ | diskpart bcdboot "$pwd\$wimMountName\Windows" /s "${vhdDisk}:" #cmd /c "$wimMountName\Windows\System32\bootsect /nt60 ${vhdDisk}: /mbr /force" $disk = gwmi win32_diskdrive -filter "Model = 'Msft Virtual Disk SCSI Disk Device'" $part = $disk.GetRelated("win32_diskpartition") | select -first 1 $bootmgr = [wmi]"root\wmi:BcdObject.Id=`"{9dea862c-5cdd-4e70-acc1-f32b344d4795}`",StoreFilePath=`"${vhdDisk}:\\boot\\bcd`"" $osloader = [wmi]"root\wmi:BcdObject.Id=`"$($bootmgr.GetElement(0x23000003).Element.Id)`",StoreFilePath=`"${vhdDisk}:\\boot\\bcd`"" $bootmgr.SetQualifiedPartitionDeviceElement(0x11000001, 0, $disk.Signature, $part.StartingOffset) $osloader.SetQualifiedPartitionDeviceElement(0x11000001, 0, $disk.Signature, $part.StartingOffset) $osloader.SetQualifiedPartitionDeviceElement(0x21000001, 0, $disk.Signature, $part.StartingOffset) $osloader.SetStringElement(0x12000002, "\Windows\system32\winload.exe") $osloader.SetStringElement(0x22000002, "\Windows") $osloader.SetBooleanElement(0x26000022, $true) md "${vhdDisk}:\Windows\System32\config\", "${vhdDisk}:\Windows\Fonts", "${vhdDisk}:\Windows\inf", "${vhdDisk}:\Windows\SysWOW64" copy -r "$wimMountName\Windows\System32\drivers" "${vhdDisk}:\Windows\System32\drivers" del "${vhdDisk}:\Windows\System32\drivers\termdd.sys" copy "$wimMountName\Windows\Fonts\vgaoem.fon" "${vhdDisk}:\Windows\Fonts" copy "$wimMountName\Windows\inf\errata.inf" "${vhdDisk}:\Windows\inf" copy "$wimMountName\Windows\System32\config\SYSTEM" "${vhdDisk}:\Windows\System32\config" copy "$wimMountName\Windows\SysWOW64\ntdll.dll" "${vhdDisk}:\Windows\SysWOW64" copy native.exe "${vhdDisk}:\Windows\System32\smss.exe" "ntoskrnl.exe", "hal.dll", "ci.dll", "pshed.dll", "clfs.sys", "kdcom.dll", "ntdll.dll", "apisetschema.dll", "winload.exe", "bootvid.dll", "bootres.dll", "l_intl.nls", "c_1252.nls", "c_437.nls" |% { copy (Join-Path "$wimMountName\Windows\System32" $_) "${vhdDisk}:\Windows\System32" } @" select vdisk file=$pwd\$vhdName detach vdisk "@ | diskpart dism /unmount-wim /mountdir:$wimMountName /discard

यह कुछ इस तरह दिखता है:

यदि सब कुछ सही तरीके से किया जाता है (और कुछ भाग्य :-) के साथ), तो कुछ समय बाद डिस्क.vhd फ़ाइल उसी निर्देशिका में दिखाई देगी - इसे एक वर्चुअल मशीन में चलाया जा सकता है (वर्चुअलबॉक्स में परीक्षण किया गया है, लेकिन मुझे कोई कारण नहीं है कि ऐसा क्यों नहीं करना चाहिए वर्चुअल पीसी, हाइपर-वी या कहीं और काम करना):

खैर, कुछ टिप्पणी अंत में।

1. लगभग 300 ड्राइवरों को कॉपी किया जाता है, डाउनलोड किया जाता है - लगभग 100, वास्तव में एक विशिष्ट सिस्टम पर आवश्यक - 10-20 टुकड़े।

2. इंस्टॉल से आठ मेगाबाइट सिस्टम का उच्च। बूट से दो मेगाबाइट के साथ सामान्य रूप से प्रतिस्थापित किया जा सकता है। या आप सौ किलोबाइट तक मैन्युअल रूप से कुछ अंधा कर सकते हैं।

3. bcdboot सभी बूटमग्र स्थानीयकरण और फोंट के कई मेगाबाइट की प्रतिलिपि बनाता है (मुख्य रूप से CJK के लिए) - आप काट सकते हैं

4. आप देख सकते हैं कि छवि बनाते समय termdd.sys हटा दिया गया है - ऐसा इसलिए नहीं है क्योंकि यह काम नहीं करता है। यह सिर्फ एक अन्य कीबोर्ड डिवाइस बनाता है (जो कि सामान्य मोड में टर्मिनल सत्र में रिमोट मशीन पर "बटन दबाएं") और सभी कीबोर्ड से कीस्ट्रोक्स पढ़ने के लिए native.exe को संशोधित करने के लिए बहुत आलसी था।

5. आप बूट पर ग्राफिक्स दबा सकते हैं और bootvid.dll और bootres.dll को मना कर सकते हैं

अच्छी तरह से और सबसे महत्वपूर्ण बात, win32k.sys बनाई गई छवि की नकल नहीं है, जो इस छवि को ग्राफिक्स के बिना अपेक्षाकृत अच्छी तरह से काम करने से नहीं रोकता है। एक बड़ी इच्छा के साथ, जैसा कि मैंने कहा, आप पूरी तरह से कंसोल शेल को स्क्रू कर सकते हैं, आप विंडोज सबसिस्टम को काट सकते हैं और केवल पॉज़िक्स छोड़ सकते हैं (यह मेरे लिए एक बहुत ही अजीब इच्छा होगी, लेकिन लोग अक्सर एक अजीब चाहते हैं)। या (यहां तक कि एक अजनबी इच्छा) देशी कर्नेल को NT कर्नेल के शीर्ष पर लागू करने के लिए। आप smss की जगह ले सकते हैं और कर्नेल के ऊपर काम करने वाली हर चीज़ को "पूरी तरह से नियंत्रित" कर सकते हैं, या आप smss छोड़ सकते हैं और लोड किए गए सबसिस्टम के सेट को रजिस्ट्री में कुछ संपादन के साथ बदल सकते हैं। संक्षेप में, बस कोई ग्राफिक्स नहीं है "कसकर मूल को पकड़ा"।

आपका ध्यान देने के लिए धन्यवाद।

"घातक रूप से मूल" ग्राफिक्स सबसिस्टम पर ले जाया गया

अभ्यास सच्चाई की कसौटी है या "घुटने पर मिनविन"

More articles: