Driverele modului kernel: Partea 1: Concepte de bază - Arhiva Wasm.ru

Prezentare generală a arhitecturii

Lumea interioară a Windows 2000 este împărțită în două părți cu limite clar desemnate, atât în \u200b\u200bceea ce privește spațiul de adresare, cât și în ceea ce privește drepturile și îndatoririle Codului în acest spațiu de adresă al Executivului.

Cu separarea spațiului de adrese, totul este surprinzător de simplu. Toate cele patru disponibile în arhitectura pe 32 de biți, gigabytes sunt împărțite în două părți egale (tuning RAM 4GT și extensie de adresă fizică I inferior ca zczotic). Jumătate inferioară este dată proceselor modului de utilizator, partea de sus aparține kernel-ului.

Odată cu separarea drepturilor și responsabilităților, puțin mai dificilă.

Următoarele procese includ utilizatorul:

• Procesele de susținere a sistemului (procese de suport pentru sistem) - de exemplu, procesul de intrare în sistemul WinLogon (implementat în \\% SystemRoot% \\ System32 \\ Winlogon.exe);
• Servicii Procese (procese de service) - De exemplu, o bobină de imprimare;
• Aplicații personalizate (aplicații de utilizator) - Există cinci tipuri: Win32, Windows 3.1, MS-DOS, POSIX și OS / 2;
• Subsistemele de mediu (subsisteme de mediu) - Cele trei subsisteme de mediu sunt acceptate: Win32 (implementat în \\% SystemRoot% \\ System32 \\ CSRSS.exe), POSIX (implementat în \\% SystemRoot% \\ System32 \\ PSXSS.exe), OS / 2 ( Implementat în \\% SystemRoot% \\ System32 \\ OS2SS.exe).

Kernel-ul este alcătuit din următoarele componente:

Sistemul executiv (Executive) - Managementul memoriei, procesele și firele etc.;
• Kernel - planificarea fluxului, dispecerarea întreruperilor și excepțiilor etc. (implementat în \\% SystemRoot% \\ System32 \\ ntoskrnl.exe);
• Drivere de drivere de dispozitiv - Drivere hardware, drivere de rețea, drivere de sistem de fișiere;
• Stratul abstract hardware, Hal - izolează cele trei componente ale componentei de mai sus din diferențele dintre arhitecturile hardware (implementate în \\% SystemRoot% \\ System32 \\ Hal.dll);
• Sistem de ferestre și grafică (interfață de utilizator grafică, GUI) (Implementat în \\% SystemRoot% \\ System32 \\ Win32k.sys).

Smochin. 1-1. Schema de arhitectură Windows 2000 simplificată

Modul utilizatorului și modul kernel

Deși procesoarele familiale Intel X86 susțin patru niveluri de privilegii (numite inele de protecție), numai două sunt utilizate în Windows: 0 Oh pentru modul kernel și 3 pentru modul utilizator. Acest lucru se datorează sprijinului altor procesoare (Alpha, MIPS), în care sunt implementate doar două niveluri de privilegii. Edițiile anterioare ale Windows NT au susținut aceste arhitecturi, dar numai suportul X86 a rămas în Windows 2000.

Componentele modului de utilizator au propriile spații de adrese protejate, aceste fluxuri de procese sunt efectuate în modul de procesor ne-privilegiat (numit utilizator), nu poate efectua comenzi de procesor privilegiat, au acces limitat și mediate la datele de sistem și la spațiul de adrese al sistemului, Nu există direct echipament de acces. Adevărat, în procesul de lucru, fluxurile acestor procese, apelurile de sistem, accesați modul kernel, dar în acest caz pierde complet controlul asupra executării sale înainte de a reveni la modul utilizator.

Procesele de regim de utilizare sunt considerate ca fiind potențial periculoase în ceea ce privește stabilitatea sistemului. Drepturile lor sunt limitate. Și tot felul de încercări de a depăși aceste restricții sunt greu de oprit.

Componentele kernel-ului partajează un spațiu de adresă, efectuat în modul Procesor privilegiat (numit modul kernel), poate efectua totul, inclusiv comenzi privilegiate, procesor, au acces nelimitat și direct la datele și codul sistemului, au direct sau prin HAL, Accesul la echipament.

Codul de bază (de fapt acesta este sistemul în sine) este considerat a fi complet de încredere. Prin urmare, fiind încărcat în spațiul adresei sistemului, șoferul devine parte din sistem, iar orice restricții nu sunt suprapuse pe ea.

Astfel, aplicațiile utilizatorului sunt separate de sistemul de operare în sine. Dacă specificați obiectivul de scriere pentru o anumită aplicație serioasă, pentru a lucra cu funcțiile interne sau structurile de date ale sistemului, veți întâlni o multitudine de restricții, pentru a depăși, pe care nu vă puteți poseda codul în spațiul de adrese al sistemului. Din documentele documentate există doar o singură modalitate de a face acest lucru - Instalați driverul dispozitivului. Această metodă este relativ simplă, fiabilă și, cel mai important, furnizată integral cu suport din partea sistemului de operare în sine.

Windows 2000 Drivere

Windows 2000 acceptă mai multe tipuri de drivere de dispozitiv.

Există doi de bază care au reprezentanții lor:

• Drivere de moduri de utilizator: Drivere de utilizator:
  • Driverele de dispozitive virtuale, VDD-urile sunt utilizate pentru a susține programele MS-DOS (nu trebuie confundate cu driverele VXD în Windows 95/98 - acestea sunt lucruri complet diferite, deși au un nume);
  • Drivere de imprimantă.
• Driverele modului de kernel (drivere de tip kernel):
  • Drivere de fișiere (drivere de sistem de fișiere) - implementați intrarea și ieșirea la unitățile locale și de rețea;
  • Legacy Drivere - scrise pentru versiunile anterioare ale Windows NT;
  • Drivere de drivere video - Implementarea operațiunilor grafice;
  • Streaming Drivere - Drivere de streaming - Implementați video și sunet I / O
  • Drivere WDM (modelul driverului Windows, WDM) - Suport Plag și redarea tehnologiei și gestionarea energiei electrice. Caracteristica lor distinctivă este compatibilitatea la nivelul codului sursă între Windows 98, Windows Me și Windows 2000.

În diferite surse, puteți întâlni o clasificare ușor diferită de cele de mai sus, nu este importantă. Este important ca șoferii pe care să o scriem, nu se încadrează în niciun element al acestei clasificări. Acestea nu sunt nici drivere de sistem de fișiere, nici drivere moștenite, nici drivere de adaptoare video sau carduri audio, nici drivere WDM, deoarece Nu suportați placa "n" și controlul puterii. Acestea nu sunt drivere de regim de utilizare (nu este interesant deloc). De fapt, doar știe ce este, pentru că Sistemul în sine vă permite să adăugați cu ușurință și pur și simplu codul în sine nu este clar pentru ce dispozitiv și faceți ceva cu el! Acesta este modul în care ați avut un om complet nefamiliar pe timp de noapte pe ușă noaptea și nu ați spune un cuvânt să-l lase noaptea și aș fi pus în patul meu! Cu toate acestea, nu este un fel de bug sau o gaură în sistemul de securitate. Doar funcționează sistemul pe măsură ce funcționează. În caz contrar, nu poate, pentru că Interacționarea cu mediul, sistemul este forțat să ofere acces. Și dacă nu ar fi fost așa, ar fi complet închis și, prin urmare, un sistem inutil.

După cum rezultă din Numele, driverul dispozitivului este un program conceput pentru a controla un dispozitiv, iar dispozitivul nu trebuie să fie fizic. Poate fi logic sau, ca în cazul nostru, virtual.

Prin structura sa, driverul dispozitivului este altceva ca format PE (executabil portabil, PE). La fel ca exe și DLL obișnuit. Doar încărcate și lucrează pe alte reguli. Driverele pot fi considerate ca DLL din modul kernel conceput pentru a efectua sarcini care nu sunt rezolvate din modul utilizator. Diferența principală (care nu numărăm nivelul de privilegii) este că nu vom accesa direct conducătorul auto, nici la codul său, nici la datele sale și vom folosi mecanismul special furnizat de dispecerul I / O (administrator de intrare / ieșire ). Dispecerul I / O oferă un mediu pentru funcționarea driverelor și oferă, de asemenea, mecanisme de descărcare, descărcare și gestionare a acestora.

Începeți de dezvoltarea driverelor de regim de kernel, veți simți noul nou-veniți perfect, deoarece Întreaga experiență anterioară de utilizare a API nu va ajuta aici - kernelul oferă un set complet diferit de funcții. De asemenea, va trebui să utilizați slab documentat (definit numai în fișierele de antet) sau la toate funcțiile nedocumentate și structurile de date.

Drivere single și multi-nivel

Majoritatea driverelor de dispozitive fizice controlate sunt multi-nivel (drivere stratificate). Procesarea cererii I / O este împărțită între mai multe drivere. Fiecare își îndeplinește partea din lucrare. De exemplu, un cititor de fișiere este transmis la driverul sistemului de fișiere, care, după ce a finalizat unele operații (de exemplu, împărțirea unei interogări în mai multe părți), transmite unitatea "de mai jos", iar cea, la rândul său, trimite a solicitați conducătorului auto. În plus, pot fi adăugate orice număr de drivere de filtru între aceste drivere (de exemplu, datele de bifare). Solicitarea driverului de subordonare (driverul de nivel inferior) transmite rezultatele acestuia "sus" la cel mai înalt (driver de nivel superior). Dar, din fericire, toți vom fi mult mai ușor. Driverele noastre vor fi întotdeauna unice (drivere monolitice), ceea ce va simplifica foarte mult întregul proces de scriere și depanare a acestora.

Contextul inundațiilor

Deoarece, în majoritatea cazurilor, avem doar un singur procesor, iar aplicațiile care trebuie să le îndeplinească foarte mult sunt, este firesc ca să creeze iluzia executării simultane, este necesar să le conectăm în mod consecvent la procesor și foarte repede . Această procedură se numește contextul de comutare a contextului firului. Dacă sistemul comută contextul fluxurilor aparținând aceluiași proces, atunci este necesar să se salveze valoarea registrelor procesorului fluxului de închidere și de încărcare, valori pre-stocate ale registrelor procesorului plug-in . Și să actualizați unele structuri de date. Dacă plug-in-ul aparține unui alt proces, atunci este necesar să se descărcați un indicator în directorul paginii din registrul CR3 al procesorului (director de pagini) al procesului. Deoarece fiecare proces utilizator este prevăzut cu un spațiu de adrese închise, există diferite procese de spații de adrese, ceea ce înseamnă diferite directoare de pagini și seturi de pagini pentru care procesorul traduce adresele virtuale în fizice. Toate acestea nu sunt legate direct de driverele de programare. Dar îmi amintesc de acest lucru în legătură cu care. Deoarece operația de comutare a contextului nu este cea mai rapidă, atunci șoferii, din motive de performanță mai bună, de regulă, nu creează fluxurile lor. Dar codul șoferului trebuie să fie încă efectuat. Prin urmare, pentru a economisi timp pentru a comuta contexte, driverele sunt efectuate în modul kernel într-unul din cele trei contexte:

• În contextul fluxului de utilizator al cererii I / O inițiale;
• În contextul fluxului de sistem al modului de kernel (aceste fluxuri aparțin procesului de sistem);
• ca urmare a întreruperii (și, prin urmare, nu în contextul unui proces sau al unui flux, care a fost curent la momentul întreruperii).

Nu înțeleg destul de cum puteți efectua ceva "nu în contextul oricărui proces sau al fluxului", dar luați în considerare autoritatea oamenilor pe care au scris-o (D. Solomon și M. Russinovici), precum și ceea ce nu avem nevoie de ea , pentru că. Nu vom gestiona nici unul de software, nu mai, întreruperile hardware, despre al treilea caz pe care îl puteți uita imediat. Primele două opțiuni rămân. Dacă este inițiată o interogare I / O, atunci, în contextul fluxului acestei solicitări inițiate și înseamnă că putem accesa direct spațiul de adresă al cărui flux aparține. Dacă suntem în contextul fluxului de sistem, atunci pot fi legate direct de orice proces utilizator și putem contacta întotdeauna sistemul. Dacă aveți nevoie de la șofer pentru a vedea ce fel de proces este într-un astfel de proces, va trebui fie să comutați contextul în sine sau să difuzați adresele la tabelele de pagină.

Întrerupeți nivelurile de interogare

Întreruperea este o parte integrantă a oricărui sistem de operare. Întreruperea necesită prelucrare, astfel încât executarea opțiunilor curente de cod și controlul este transmis dispozitivului de funcționare a întreruperii. Există atât întreruperi hardware, cât și software-ul. Întreruperile sunt deservite în funcție de prioritatea lor. Windows 2000 utilizează scheme de prioritizare a întreruperii cunoscute sub numele de niveluri de interogare de întrerupere (niveluri de cerere de interorare, IRQL). În total, există 32 de nivele, de la 0 (pasiv) având cea mai mică prioritate, 31 (înălțime), având cea mai înaltă calitate, respectiv. Mai mult, întreruperile cu IRQL \u003d 0 (pasiv) prin IRQL \u003d 2 (DPC \\ Dispatch) sunt software și întreruperile cu IRQL \u003d 3 (dispozitivul 1) prin IRQL \u003d 31 (înălțime) sunt hardware. Nu confundați nivelurile de prioritate de întrerupere cu nivelurile prioritare ale fluxului sunt complet diferite. Întreruperea cu nivelul irql \u003d 0, strict vorbind, nu este întreruperea, pentru că Nu poate întrerupe funcționarea oricărui cod (deoarece acest cod ar trebui să fie efectuat la un nivel chiar mai scăzut de întrerupere, dar nu există un astfel de nivel). Pe acest IRQL, se efectuează fluxurile de regim de utilizare. Și codul driverelor noastre va fi, de asemenea, efectuat pe acest IRQL. Acest lucru nu înseamnă că codul oricărui șofer este întotdeauna efectuat la nivelul "pasiv". Pur și simplu nu vom gestiona niciun software, nici mai multe întreruperi hardware. Și de aici, cel puțin două ieșiri foarte importante.

În primul rând: Lucrarea șoferilor noștri poate fi întreruptă în orice moment, pentru a procesa întreruperea cu o prioritate mai mare (de exemplu, de la cronometru, când planificatorul va considera că fluxul nostru și atât de mult are un procesor de mult timp și este timpul pentru relaxare). Prin urmare, în acest sens, codul șoferilor noștri este întrerupt și deplasat (procesorul este dat unui alt flux), la fel ca codul oricărui flux de utilizator. Există funcții nucleus care vă permit să aflați nivelul actual de întrerupere, precum și creșterea sau reducerea acesteia.

Cel de-al doilea punct important: la nivelul de întrerupere pasivă, puteți apela orice funcție de kernel (în DDK în descrierea fiecărei funcții, este necesar să se specifice la ce întrerupere nivel poate fi numit) și, de asemenea, accesați paginile de memorie abandonate în Fișier de paginare. La niveluri mai mari de întrerupere (DPC / Dispath și mai mare), o încercare de a face apel la pagina lipsește în memoria fizică duce la prăbușirea sistemului, deoarece Managerul de memorie (managerul de memorie) nu poate gestiona eroarea de pagini.

"Ecranul de moarte albastră"

Cred că toată lumea, cel puțin o dată, a văzut o imagine interesantă numită "Ecranul de moarte albastră" (ecranul albastru al morții, BSOD). Probabil că nu este nevoie să explicați ce este și de ce se întâmplă. Este important aici că prin dezvoltarea driverelor de mod al kernelului, pregătiți-vă pentru faptul că BSOD va apărea adesea pe ecranul monitorului.

În al treilea inel, totul a fost simplu: schițat un cod exemplar, pus int3 unde a fost necesar, am lansat și ... în depanator, deja dezmembrați ce. Dacă ceva este greșit, au greșit greșelile, recompilează ... și așa mai departe, până când codul câștigă așa cum ar trebui. Când programați drivere despre această tehnică puteți uita. Aici "Sapper" se înșeală o singură dată. O mișcare incorectă ... și vă puteți sprijini pe spatele scaunului și vă puteți relaxa pentru un minut.

Pentru a vedea BSOD-ul cât mai mult posibil, ar trebui să rămâneți la o regulă foarte simplă: "De șapte ori va muri - o tăietură" ... în sens "de șapte ori verificați - o fugă". Cu siguranță, spune doar, dar este mult mai greu de făcut. Dar, de regulă, având în vedere faptul că structura șoferilor pe care o veți scrie (după citirea acestor articole) este relativ simplă, puteți face față erorilor înainte de apariția BSOD. Dacă el apare în mod persistent în fața ochilor tăi și nu puteți înțelege motivul, este posibil să se clarifice situația este analiza depozitului de urgență (halda de cazare). Faptul că este modul de a face acest lucru și analiză poate fi citit în articolul lui Mark Russinovici "Analiza haldelor de memorie de urgență" http://www.osp.ru/win2000/2001/03/025.htm. Aceasta este (analiza) este foarte dificilă, dar cred că nu o voi ajunge.

Theoristul ME este timid, astfel încât toate cele de mai sus pot fi privite ca informații foarte fundamentale despre aceste principii care sunt absolut necesare pentru a înțelege. Este imposibil să începeți să dezvoltați driverele modului de kernel fără a avea un concept că un astfel de context flux, niveluri de întrerupere și priorități ale fluxurilor, modul de kernel / utilizator etc. etc. Simțiți-vă că nu sunteți sigur de o întrebare - o listă de referințe este mai mică.

Acum a aprins câteva lucruri practice (ele vor deveni destul de practice în următoarele articole), și anume ceea ce trebuie să transformăm în practică toată această teorie.

Kit de dezvoltare a șoferului.

Primul este, bineînțeles, un set de kit de dezvoltare a driverului de dispozitiv (Windows 2000 Driver Development Kit, 2kddk), care poate fi descărcat în mod liber de la Microsoft (în orice caz, am fuzionat complet gratuit de aici: http://www.microsoft. COM / DDK /). Acest pachet include documentația care este o sursă bogată de informații privind structurile de date interne și funcțiile intrasisteme utilizate de driverele de dispozitiv.

În plus față de documentația din DDK, un set de fișiere de bibliotecă (* .lib), care va fi absolut necesar atunci când aspectul. DDK include două seturi de aceste fișiere: pentru versiunea finală a Windows (numită Liber Build); Și pentru depanare (numită eliberarea de verificare (construirea verificată)). Aceste fișiere sunt în cataloage% DDK% \\ libfre \\ i386 și% DDK% \\ Libchk \\ i386, respectiv. Versiunea de depanare este caracterizată printr-o verificare mai strictă de eroare. Trebuie să utilizați fișiere corespunzătoare versiunii sistemului prin plasarea acestora în directorul \\ MASM32 \\ lib.

Fișierele includ

De asemenea, vom avea nevoie de fișiere activate (* .inc) cu definiții ale prototipurilor de funcții. De asemenea, vom trebui să le facem (mai exact pentru mine). Am încercat o mulțime de utilități diferite Conversia * .lib -\u003e * .inc, ambele incluse în pachetul Masm32 prin cabană și au fuzionat cu mine la momente diferite, cu Internet fără sfârșit. Din tot ceea ce am în stoc, doar protoize.exe de F0DDDER sa confruntat cu sarcina mea și practic nu trebuia să conduc nimic cu mâinile mele. Această minunată Tulza va fi în directorul \\ instrumente \\ protoize. Site-ul autorului: http://f0dder.didjitatalyfrozen.com/. Numai nu o veți găsi acolo. F0DDDER a trimis acest utilitar de mai multe ori în cadrul conferinței http://board.win32asmcommunity.win32asmcommunity.ro/. Include va sta în directorul \\ Include \\ W2K. Acestea ar trebui plasate în Catalogul \\ MASM32 \\ Include \\ W2K. * .Lib a fost folosit pentru conversie pentru eliberarea gratuită a Windows 2000, deoarece am exact această opțiune (și probabil că și tu).

Următoarea problemă este mai gravă. Este aproape absența completă a fișierelor incluse în definițiile structurilor necesare, constantelor simbolice și macrocomenzilor. Nu puteți găsi cu greu ceva curat pe rețea - cu greu puteți fi prea exotic această lecție - scrieți driverele modului de kernel pe asamblare. Ceva poate fi găsit la elicz http://www.centracking.sk/elicz/. Ceva în Y0DA http://mitgled.lycos.de/yoda2k/index.htm (parțial realizat de el însuși, parțial preluat din același Elicz). Dar acest lucru se face din mâna rău, (cu tot respectul meu profund pentru colegii noștri slovaci și germani): numele membrilor multor structuri diferă de cele definite în fișierele originale ale antetului din DDK; Structurile și interblocările imbricate nu au nume; Deși în original sunt chemați. Și, în general, totul este într-o anumită tulburare, iar atunci când vizionarea provoacă o impresie deprimantă. Nu este rău doar ntstatus.inc. Parțial, acest lucru se explică prin faptul că Elicz a început să-și creeze includul în absența DDK (așa cum spune el însuși). În orice caz, nu vă sfătuiesc să le utilizați, cel puțin fără verificarea atentă. Ceva, la un moment dat, a strălucit în conferință http://board.win32asmcommunity.win32asmcommunity.win32asmcommunity.win32asmcommunity.ro/, dar calitatea nu este, de asemenea, foarte impresionantă. Pe scurt, singura soluție corectă din această situație este de a face totul singur, și manual, deoarece orice unelte care vă permit să automatizați acest proces, nu știu. Dacă, brusc, întâlniți ceva util, nu gândiți-vă la muncă - spuneți-mi.

Depanarea driverelor

De asemenea, avem nevoie de un debugger și, deoarece codul modului de bază va trebui să depaneze, atunci debuggerul are nevoie de cea potrivită. Cea mai bună alegere va fi softice. Sau puteți utiliza partea de depanare a kernel-ului DDK. Acest debugger necesită două computere - plumbul și condus, ceea ce nu este toată lumea își poate permite. Mark Russinovich (Mark Russinovich, http://www.sysinternals.com/) a scris un utilitar Livekd care vă permite să utilizați depanarea kernel fără a conecta cel de-al doilea computer. Nu știu dacă este pe site (nu este verificat), dar pe disc în cartea "Dispozitivul intern Microsoft Windows 2000" este disponibil. De asemenea, acest debugger este extrem de util pentru studiul sistemului intern al sistemului, cu condiția să fi selectat caracterele pe care le puteți (sau ați fost posibile) descărcați gratuit de la Microsoft.

David Solomon, Mark Russinovici, "Interiorul Microsoft Windows 2000", Ed. "Peter", 2001.

Deși nu există o singură linie de cod sursă în această carte, este în primul rând programatori.

Sven Shreiber, "Caracteristici nedocumentate ale Windows 2000", Ed. "Peter", 2002.

O carte pur practică în care este dezvăluită o mulțime de secrete de Windows 2000.

Walter Oney, "programarea modelului Microsoft Driver", Microsoft Press, 1999

În această carte, opritorul se face pe driverele de joacă Plag "N", dar acest lucru nu implorește, deloc avantajele sale, pentru că Principiile de bază pentru dezvoltarea driverelor sunt universale.

Jeffrey Richter ", ferestre pentru profesioniști: crearea unor aplicații Win32 eficiente, luând în considerare specificul versiunii pe 64 de biți a Windows", Ed. "Peter", 2000.

Această carte nu are nicio atitudine directă față de programele de programare, dar și foarte interesant ;-)

Această listă nu susține în nici un caz exhaustivitate. Multe, în special în limba engleză, pot fi găsite pe Internet (cu excepția Shreiber, toate cărțile sunt în versiunea electronică). În ceea ce privește cărțile pe care vreau să le spun din nou că sunt toate din categoria "trebuie să aibă". Vedeți - Cumpărați fără să căutați. Totul, cu excepția lui Walter ", iar Oney este tradusă în" Mare și Mighty ".

Și ultimul. Nu sunt un specialist mare în dezvoltarea șoferilor, astfel încât greșelile sau inexactitățile, atât în \u200b\u200bacest articol, cât și în toate articolele ulterioare, sunt foarte probabile. Veți găsi - îndrăznețați-vă nasul. Voi spune mulțumesc.

Centrul de securitate Windows Defender, inclusiv o nouă secțiune de securitate a dispozitivului, care oferă instrumente de securitate îmbunătățite, cum ar fi izolația kernelului.

Izolarea kernelului este o tehnologie de securitate bazată pe virtualizare, care oferă un nivel suplimentar de protecție împotriva atacurilor inteligente. Integritatea memoriei este una dintre componentele tehnologiei de izolare a kernelului - funcția este destinată să prevină introducerea codului rău intenționat în procese de înaltă securitate. Protecția este asigurată datorită faptului că pagina de memorie virtuală a kernelului începe numai după trecerea de succes a verificării integrității.

Luați în considerare modul de a activa funcția "Integritatea memoriei" în Windows 10 aprilie 2018 Update pentru a spori securitatea calculatorului.

Activați integritatea memoriei

• Deschideți Centrul de securitate Windows Defender.
• Selectați secțiunea "Siguranța dispozitivului".

• În secțiunea "Secțiunea izolației kernel", faceți clic pe linkul "Informații despre izolația nucleului".
• Deplasați comutatorul integrității memoriei în poziția activă.

După finalizarea acestor acțiuni, trebuie să reporniți computerul astfel încât modificările să aibă efect.

Notă: Pentru a lucra această caracteristică, procesorul dvs. trebuie să sprijine tehnologiile de virtualizare. În plus, virtualizarea trebuie să fie activată în BIOS sau în UEFI. În caz contrar, funcția va fi indisponibilă.

Corectarea problemelor de izolare a kernelului

În unele cazuri, puteți întâmpina probleme de compatibilitate în unele aplicații, dacă izolarea kernel-ului este pornită. Pentru a repara problemele vor trebui să dezactiveze funcția.

Dacă încercați să dezactivați integritatea memoriei în Centrul de securitate Windows Defender, dar opțiunea a devenit inactivă și mesajul este afișat. "Acest parametru acționează administratorul dvs., apoi puteți dezactiva funcția utilizând registrul de sistem.

Notă: Schimbarea incorectă a registrului poate duce la probleme grave. Se recomandă crearea unei copii de rezervă a registrului Windows înainte de a efectua acești pași. În meniul Editor Registry, selectați File\u003e Export pentru a salva backupul.

• Apăsați combinația de taste Windows + R pentru a afișa fereastra "Run".
• Introduceți Regedit și faceți clic pe OK pentru a porni editorul de registry.
• Du-te la următorul mod:

Hkey_local_machine \\ sistem \\ CurrentControlset \\ Control \\ DeviceGuard \\ Scenarios \\ HypervisorenForcedCodeigrity

• Dublu click Activat..
• Schimbați valoarea de la 1 la 0.
• Faceți clic pe OK.

Pentru a dezactiva, puteți utiliza, de asemenea, gata

Trimiteți-vă munca bună în baza de cunoștințe este simplă. Utilizați formularul de mai jos

Elevii, studenți absolvenți, tineri oameni de știință care folosesc baza de cunoștințe în studiile și munca lor vă vor fi foarte recunoscători.

Postat pe http://www.allbest.ru/

1. Informații teoretice

1.1 Dezvoltarea driverelor de kernel Windows

Informații teoretice scurte

Dezvoltarea driverelor de kernel

Șoferul (de la driverul englez) este un program de calculator cu care un alt program (de obicei sistemul de operare) câștigă acces la hardware-ul standard.

Schematic, pentru a arăta cât de diferite tipuri de drivere funcționează:

Convenabil împărțit în 2 tipuri:

- Drivere de kernel (lucrați la nivelul privilegiilor, dar nu interacționați cu niciun program de utilizator, nici cu dispozitivul. Din ele vom începe (ei pot beneficia și de ei).

Driverele de dispozitiv sunt necesare pentru a interacționa între programul utilizatorului și dispozitiv, și anume, transmit date între ele, controlați dispozitivul. În plus, dispozitivele pot fi atât reale, cât și virtuale). Șoferul nu trebuie să gestioneze niciun dispozitiv fizic. Unele sisteme de operare fac posibilă crearea și driverele dispozitivelor virtuale - obiecte care se comportă în mod similar cu dispozitive, dar nu răspund la niciun dispozitiv fizic.

Componentele kernel-ului sunt efectuate în modul procesor privilegiat (numit modul kernel), pot efectua totul, și anume:

- pot efectua comenzi de procesoare privilegiate (de exemplu, LGDT),

- pot avea acces la datele și codul sistemului,

- au acces direct la echipamente, cum ar fi porturile

- au acces la celulele de memorie; Șoferul nu poate manipula direct memoria fizică, dar poate obține o adresă virtuală pentru orice fizic și manipulați-le.

Dacă aveți nevoie să scrieți la o anumită aplicație serioasă, să lucrați cu acces la funcții interne sau structuri de date de sistem, puteți întâlni o multitudine de restricții, pentru a depăși numai emisiile codul dvs. în spațiul de adrese al sistemului. Din documentele documentate există doar o singură cale de a face acest lucru - instalați driverul. Această metodă este relativ simplă, fiabilă și, cel mai important, furnizată integral cu suport din partea sistemului de operare în sine.

Codul de bază (de fapt acesta este sistemul în sine) este considerat a fi complet de încredere. Prin urmare, fiind încărcat în spațiul adresei sistemului, șoferul devine parte din sistem, iar orice restricții nu sunt suprapuse pe ea. În Windows, este aproape singura modalitate de a scrie dezvoltatori de operare pentru a scrie componente de sistem ale kernel-ului.

DDK (Kit de Dezvoltare a dispozitivului) este utilizat pentru a scrie și a explora metodele de dezvoltare a șoferului - sistemul de dezvoltare a driverelor.

În plus față de documentația din DDK, este inclus un set de fișiere incluse (* .inc) și fișierele de bibliotecă (* .lib).

Astfel, Windows suportă diverse tipuri de drivere de dispozitive, dar, în plus, există drivere care nu sunt drivere de dispozitive, dar vă permit pur și simplu să creați programe care vor funcționa în Windows în modul kernel, adică La nivelul privilegiilor. În același timp, accesează pe deplin sistemul de operare și echipamentul.

Luați în considerare cel mai simplu driver mod de kernel.

#Include.

int diverrentry (

În pdriver_object pdriverrobject,

În PusregistStryPath) (

}

Punctul de intrare este Diververry, care este decorat sub forma unei proceduri de găzduire a doi parametri:

pdriverrobject - pointer la obiectul a creat driverul. Prin descărcarea driverului, sistemul creează obiectul șoferului (obiectul șoferului), reprezentând imaginea driverului în memorie. Prin acest obiect, sistemul controlează șoferul. Șoferul este o structură de date de tip Driver_Object obișnuit.

pusregistryPath - indicator la cheia de registry care conține opțiuni de inițializare a driverului.

Acest driver nostru este încărcat doar în sistem și imediat descărcat.

Acum, luați în considerare programul de șablon care va trebui utilizat pentru a dezvolta un program în prima etapă a lucrării cursului (driverul modului de kernel Beeper.sys).

Sarcina acestui driver este de a executa o notă asupra sistemului dinamic la prima octavă. Pentru a face acest lucru, șoferul utilizează instrucțiunile procesorului în și în afara, referindu-se la porturile I / O corespunzătoare. Este bine cunoscut faptul că accesul la porturile I / O este o resursă de sistem Windows protejată sacră. Încercarea de a face apel la oricare dintre acestea, atât de intrare, cât și la ieșire, din modul utilizator, duce în mod inevitabil la o excepție.

În exemplul nostru, vorbitorul va funcționa (pentru aceasta este utilizat, în special, port 61h, 0 și 1 biți, port 43h și 42h).

La începutul șoferului a definit toate cele 12 note.

Va fi necesar să nu porniți pur și simplu difuzorul, ci să setați frecvența sunetului. Aceasta utilizează un subsistem temporizator care funcționează independent de procesor și are 3 canale. Ieșirea canalului 2 este asociată cu difuzorul, care este utilizat pentru a genera sunetul de frecvență diferită. Audierea intervalului de sunet - 30Hz-6000Hz.

Pentru a seta frecvența sunetului la portul 43H (registrul temporizatorului) 0BH Word de control este trimis:

mOV AL, 0BH

out 43h, al

Această valoare determină numărul canalului pe care îl vom gestiona, tipul de operație, modul canal și formatul contorului.

Apoi, frecvența sonoră recalculată (1193167 / frecvență (Hz)) este trimisă la portul 42h (1193167 / frecvență (Hz) (partea mai mică este mai întâi, apoi cea mai veche).

De exemplu, vrem să obținem frecvența sunetului de 100 Hz. Recalculați frecvența

1193167/100 = 11931

Atunci:

mOV AX, 11931

out 42h, al

mOV AL, AH

out 42h, al

În prima etapă a cursului de lucru, trebuie să schimbați programul astfel încât să ofere alte sunete muzicale (fiecare prin opțiune).

Adesea, în sarcinile de care aveți nevoie pentru a stabili diferite durate. Pentru a face acest lucru, este convenabil să utilizați procedura DO_Delay, trecând indirect un parametru specific de "timp de sunet".

Pentru a face convenabil să depanați un conducător auto, există diferite mijloace. Cea mai simplă este de a fi în concluzie cu informațiile necesare în fereastra specială a utilității de vizualizare a debugului. Anterior, acest program este pornit, configurat să intercepteze mesaje de la kernel. Pentru a afișa programul, funcția DBGPRINT este apelată, având un parametru - ieșirea șirului. După pornirea driverului în fereastra de vizualizare a debugului, este afișată întreaga ieșire.

Există diferite modalități de instalare a driverului în kernel. Deoarece șoferul nostru, de fapt, nu este necesar, sistemul nu este necesar (nu conduce niciun dispozitiv), apoi vom conecta temporar șoferul la sistem și apoi vom șterge.

Pentru a face acest lucru, trebuie să creați o aplicație care va conduce driverul. Cum? Șoferul este serviciul la nivel de kernel. Prin urmare, aplicația va utiliza SCM - manager de control al serviciului (Service Control Manager), care este inclus în Windows și rulează la nivelul utilizatorului.

Astfel, este necesar să se construiască o soluție din două proiecte: aplicarea consolei și șoferul.

Pentru a dezvolta șoferii cu dvs. trebuie să fie pre-:

- instrumentul DDK,

- Instalați variabila de mediu WNDBASE (valoarea - calea către DDK, de exemplu, E: \\ Winddk \\ 3790.1830).

Proiectul cu șoferul trebuie să fie un tip de makeFile.

Efectuați setările proiectului utilizând setările aplicației și în câmpul Linia de comandă Build pentru a înregistra un șir

ddkbuild -wnetxp chk. -Cez

ce face provocarea unui script special pentru comunicarea VC cu DDK

Dosarul actual al proiectului trebuie să conțină fișiere:

surse, makeFile, ddkbuild.cmd (script), driver de fișiere sursă.c

După construirea unui proiect, șoferul trebuie să aibă extensie. SYS.

Aplicația lansează șoferul Beeper.sys, adică prescrie-o în registru și lansează la muncă. Apoi, după finalizare, îndepărtează din registru.

Pentru aplicarea pentru a rula driverul, după construirea unei soluții care constă din două proiecte - aplicații și drivere, trebuie să plasați fișierul aplicației executabile și driverul la un dosar și apoi să porniți aplicația.

Driverele sunt foarte greu de depanat. În cazul erorilor din operațiune, operațiunea este cea mai adesea înghețată, iar o repornire este necesară. Și pentru șoferul nostru, după repornire, trebuie, de asemenea, să ștergeți serviciul Beeper06 din registru utilizând Regedit (HKEY_LOCAL_MACHINE \\ SYSTEM \\ CURRENTCONLSET \\ SERVICII \\) și apoi reporniți din nou.

1.2 Drivere de dispozitiv virtuale Windows

Până în prezent, am dezvoltat un driver de mod de kernel care poate face ceea ce nu poate fi la nivelul utilizatorului, în special, să lucreze cu porturile de ieșire. Un astfel de șofer este numit driverul kernelului, dar nu un driver de dispozitiv, deoarece datele dintre programul utilizatorului și dispozitivul nu sunt transmise (la urma urmei, șoferul este de obicei necesar? Pentru a organiza schimbul de date între aplicația utilizator și dispozitiv).

Acum vom dezvolta drivere de dispozitive care transmit date și înapoi între aplicația de utilizator și dispozitiv.

Când aplicația necesită o operație A / Out, conducătorul de conducere. Pentru a face acest lucru, aplicația poate oferi o cerere de citire a datelor de pe dispozitiv sau de înregistrare a datelor pe dispozitiv. Și dacă sunt necesare alte acțiuni, de exemplu, un sondaj sau un control al dispozitivului sau altceva, așa-numitul este folosit pentru acest lucru. Interfața IOCTL (controlul dispozitivului in-out).

Vom lua în considerare acest caz special pentru dispozitivele virtuale, deoarece cel mai adesea, de ce aveți nevoie de un dispozitiv virtual în driver? Astfel încât să puteți transfera datele pe care șoferul le poate procesa într-un fel (deoarece este imposibil în aplicație) și returnați rezultatul la aplicație. Amintiți-vă că șoferul obișnuit al kernelului, discutat mai devreme, nu a luat nimic de la aplicație și nu a returnat nimic acolo, ci pur și simplu a făcut acțiuni inaccesibile cererii.

Când aplicația necesită o operație A / Out, conducătorul de conducere. Acest lucru poate fi folosit de așa-numitul. Interfața IOCTL (controlul dispozitivului in-out).

Aplicația apelantă efectuează următoarele acțiuni:

1) deschiderea fișierului și primirea descriptorului IT:

Generic_read + generic_write, 0, , open_exist, 0, null

Ca rezultat, dacă totul sa întâmplat cu succes, obținem un descriptor de dispozitiv.

2) Trimiterea unui driver de acționare a valabilității (ce să faceți, șoferul poate implementa multe acțiuni diferite):

iNVOKEIOCONTROL, descriptor, cod de acțiune, adresa tamponului de intrare, dimensiunea datelor de intrare, adresa tamponului de ieșire, dimensiunea ieșirii, adresa tampon pentru un număr real de octeți

3) Închiderea fișierului și, în consecință, eliberarea descriptorului.

invocați descriptorul dispozitivului CloseHandle

Pentru a transmite date, module (aplicații și driver) ar trebui să convină asupra protocolului de interacțiune (coduri de acțiune, structura tampoanelor - intrarea și ieșirea).

Același cod de acțiune este de asemenea utilizat în aplicație și în driver.

Un cod de acțiune în aplicație și în șofer poate fi înregistrat într-o formă de 16 ori și puteți utiliza macro-ul CTL_code, așa cum se face în exemplul laboratorului. Funcționează în fișierul comun.

Luați în considerare un exemplu de cod de acțiune de la un driver virtual al dispozitivului, care este utilizat în lucrarea de laborator. Nume - Ioctl_get.

În cazul unui dispozitiv virtual, steagul fișierului este 0.

Tipul dispozitivului - File_Device_unknown \u003d 22h

Drepturi de acces - File_read_ACcess + File_Write_ACcess \u003d 1 + 2 \u003d 3 \u003d 11b

Codul funcțional - în intervalul de la 800h la FFFH. Avem 800 ore.

Metoda de bufferizare - metoda de transferare a datelor între aplicație și driver (trei):

Pentru o cantitate mică de date, este de obicei utilizată metoda_buffered (00b) - un tampon suplimentar este evidențiat într-o memorie suficientă, suficientă pentru a plasa tamponul de intrare și ieșire. Adresa acestui tampon este situată în IRP în câmpul AssirIRP.Systembuffer. Dispecerul I / O în sine își asumă operația de rescriere a datelor între utilizator și tampon suplimentar.

Acces direct de date (fără tampon) - metoda_out_direct (2) - pentru ieșire fie Metod_in_direct (1) - pentru intrare; Câmp de la IRP - MDLADDRESS. Acesta este un apel direct - Managerul de ieșire fixează paginile fizice care conțin tamponul modului de utilizator. În același timp, creează o structură auxiliară de MDL (listă descriptor de memorie) pentru a descrie pagini fixe. Și dezvoltatorul șoferului funcționează cu MDL.

Accesul prin tampon de nivel de utilizator - metoda_netică (3); Câmp de la IRP - Systembuffer. Dispecerul I / Off trimite adresa virtuală a modului de utilizator la driver. Și în conducătorul auto trebuie să lucrați foarte atent, deoarece șoferul în acest caz ar trebui să funcționeze numai în contextul apelantului.

Când aplicația trimite driverul de cod de acțiune, începe dispecerul I / O. Este responsabil pentru generarea unui pachet de interogare I / O (pachet de solicitare I / O, IRP) și trimiterea acestuia conducătorului auto pentru prelucrare ulterioară.

Vom lua în considerare 3 tipuri de solicitări:

IRP_MJ_CREAT - va fi transferat cu CreateFile,

IRp_mj_device_control - va fi transmis cu Deviocontrol

Ipp_mj_close - cu closeHandle

Pachetul IRP constă dintr-un antet și o stive de plasare A / Out. Managerul de ieșire creează numărul de celule de stive radiante egale cu numărul de drivere implicate în procesarea cererilor. Fiecare șofer are acces la propria celulă de stivă. Când șoferul transmite pachetul IRP al driverului de nivel inferior, indicatorul la celula de stivă este mutat în celula necesară pentru acest driver. Și, dimpotrivă, după procesarea interogării, indicatorul se ridică la celula de unitate de cel mai înalt nivel. Obținerea unui indicator utilizând funcția iogetCurrentStackLocation ().

În fiecare stack de plasare există un indicator la obiectul DeviceBject și la obiectul FileOBject pentru care este inițiată interogarea. Pachetele IRP sunt întotdeauna stocate în memorie insuportabilă.

Următoarele obiecte sunt create pentru funcționarea șoferului și se aplică:

Obiectul șoferului;

Dispozitive de obiecte;

Etapele operației șoferului.

1) Crearea unui obiect de driver. Creat la încărcarea driverului la stadiul de început. În acest moment, funcția de drivereentry începe, iar matricea de responsabilizare este umplută, precum și un pointer la obiectul dispozitivului și înapoi.

Dispozitivul include:

Tipul dispozitivului.

2) Crearea unei legături simbolice cu dispozitivul. Pentru ca obiectul "Dispozitiv" să fie disponibil pentru codul modului de utilizator, șoferul trebuie să creeze în modul de utilizator accesibil mod accesibil (Mode) "\\ ??" Un alt obiect este o legătură simbolică (legătura simbolică). Driverul Shablon.sys creează link-ul simbolic SLSHABLON pe dispozitivul său "Devshablon" în directorul "\\?", Valoarea căruia este șirul "\\ dispozitiv \\ devshablon".

Astfel, atunci când încărcați șoferul (în cazul nostru, la etapa de descărcare a sistemului), avem trei obiecte în memorie: driverul "\\ driver \\ shablon", dispozitivul "\\ dispozitiv \\ shablon" și o legătură simbolică la dispozitiv " \\? \\ Slshablon ".

3) deschidere. În plus, când începe cererea, se numește CreateFile. Există o legătură cu dispozitivul. Din structura dispozitivului dispozitiv_object, informațiile sunt preluate informații despre unitatea de service. Dispecerul I / O formează pachetul de interogare IRP I / O de tip IRP_MJ_Create și îl direcționează pentru a conduce vehicule. Deci, șoferul învață că codul modului de utilizator încearcă să acceseze dispozitivul său. Dacă șoferul nu are nimic împotrivă, atunci acesta returnează codul de succes. Driverul nostru are o procedură specială de dispecerizare care răspunde la această IRP - dispeceratCreatellose (există o procedură combinată pentru deschiderea și închiderea dispozitivului). În câmpul io.status.status este transmis de status_success, și în io.status.information - 0, pentru că În acest caz, nimic nu trebuie transmis. Un astfel de răspuns din partea driverului este un semnal la dispecerul de obiecte pentru a crea un fișier virtual. În același timp, un element nou cu un indicator la obiectul "Fișier" este creat în tabelul descriptor (masa de mâner), iar un nou descriptor este returnat în modul utilizator.

Dacă totul este în regulă, atunci salvăm descriptorul de fișiere, returnat creatFile, în variabila HDevice.

4) Operații PAC. Acum avem posibilitatea de a gestiona funcționarea acestui dispozitiv prin apelarea funcțiilor DeviceIocontrol. Deoarece șoferul dispozitivului poate, în principiu, să îndeplinească multe sarcini diferite, este necesar să se diferențieze cumva cererile. În acest scop, cel de-al doilea parametru dwiocontrolcode este destinat, numit codul de control al codului de control I / O (codul de control I / O), care este construit în conformitate cu anumite reguli.

Folosind descriptorul dispozitivului, expedierea I / O va primi informații despre șoferul de service, acesta va forma un pachet de interogare I / O IRP_MJ_DEVICE_Control și îl direcționează pentru a conduce vehicule. Driverul va fi cauzat de procedura de expediere corespunzătoare, pe care codul de acțiune și informațiile despre adresele și dimensiunea tamponului de intrare și de ieșire sunt transmise ca parametri. Toate acestea sunt transmise prin IRP. Procedura IRP ia informațiile necesare: un cod de acțiune, o adresă tampon de date.

Procedura DispatchControl efectuează acțiunile necesare, în cazul nostru, adresa pachetului IRP din registrul ESI transmite apoi rezultatul prin intermediul tamponului de ieșire în aplicație.

Similar cu procedura anterioară, treceți prin starea de terminare IRP și numărul de octeți transmis de la driver.

În aplicație, aceste date sunt formatate și ieșire.

5) Închiderea. Deoarece ar trebui să fie tratată cu descriptori, care nu mai sunt necesare, apelând funcția Closehandle, închiderea descriptorului dispozitivului.

6) Descărcarea șoferului. Ștergeți o legătură simbolică și ștergeți obiectul dispozitivului.

Complexul (2) constă din două programe:

Aplicația care se referă la driverul din spatele adresei IRP și apoi această adresă afișează ferestrele în fereastra standard.

Shablon.sys - șofer.

Șoferul Shablon nu face la nivelul utilizatorului, în acest caz definește conținutul înregistrării ESI în timpul conducătorului auto.

Aplicația din tamponul de ieșire primește conținutul ESI, îl convertește la ieșirea în hexazecimal și afișează ferestrele în fereastra standard.

Dacă trebuie să primiți informații de la CMOS în driver, atunci este necesar:

Trimiteți la portul 70h offset în CMOS, care ne interesează;

Întârzierea scăzută;

Luați din portul 71h informații în Al.

Apoi scrieți aceste informații în tamponul de ieșire.

Și în aplicația trebuie să luați informații de la tamponul de ieșire, dacă este necesar, să-l convertiți și să afișați sau să analizați și, în funcție de rezultat, afișați textul necesar în fereastra standard.

În această lucrare de laborator se presupune că șoferul este instalat constant în Windows utilizând fișierul .inf utilizând elementul pentru a instala echipamentul din panoul de control: Adăugarea unui dispozitiv nou, instalați manual, afișați toate dispozitivele, instalați de pe disc, selectați FILE.INF (Driverul trebuie să fie în același folder).

Pentru a verifica dacă driverul este setat, selectați sistemul, echipamentul, managerul de dispozitiv din panoul de control.

1.3 Accesul la driverele existente din aplicațiile de regim de utilizare

Algoritmul aplicației șoferului care lucrează cu șoferul

Pentru a lucra cu șoferul șoferului, trebuie să obțineți un driver de manipulator (mâner). Acest manipulator poate fi obținut utilizând funcția CreateFile sau CreateFilea API care funcționează cu caractere ASCII. Utilizează în continuare funcția API Deviocontrol, care, ca unul dintre parametri, codul IOCTL este transmis. Codul IOCTL este un cod de gestionare cu care șoferul va învăța despre operațiune, a cărei executare solicită aplicația, metoda de transmitere a parametrilor și a drepturilor de acces pe care le cere cererea pentru efectuarea acestei operațiuni. După ce a fost cauzată cererea

Deviocontrol Drive este trimis Irp_mj_device_control. După finalizarea procesării, cererea cererilor returnează gestionarea și aplicația rămâne de a analiza răspunsul driverului și a închide descriptorii deschisi.

Exemplu

În exemplul de mai jos, aplicația modului de utilizator trimite driverul sistemului de fișiere ioctl_disk_get_partition_info_ex query_ex, analizează informațiile primite și afișează formatul partiției hard disk.

#Include.

#Include.

int _tmain (int argc, _tchar * argv)

DWORD DWBYTESTETURNED \u003d 0;

char cpartitionstyle \u003d (0);

Partition_information_ex pipartitioninfo;

Manipulați HDEVICE \u003d CreateFilea (

/*1*/" "": ",

/ * 2 * / generic_read | Generic_write.

/ * 3 * / file_share_read | File_share_write,

/ * 5 * / deschis_exist,

dacă (HDevice \u003d\u003d Invalid_handle_Value)

Messageboxa (Null, "Eroare de creafilea!", "Eroare", 0);

dacă (Deviocontrol (

/ * 1 * / (mâner) hdevice,

/ * 5 * / & pipartitioninfo,

/ * 6 * / Sizeof (pipartitioninfo),

/ * 7 * / & dwbytesreturned,

dacă (pipartitioninfo.partitionstyle \u003d\u003d partiție_style_mbr)

Messageboxa (Null, "partiție_style_mbr", "Caption", 0);

altfel dacă (pipartitioninfo.partitionstyle \u003d\u003d partiție_style_gpt)

Messageboxa (Null, "partiție_style_gpt", "Caption", 0);

Messageboxa (Null, "partiție_style_raw", "Caption", 0);

Messageboxa (Null, "Eroare de Deviocontrol", "Eroare", 0);

CloseHandle (HDevice);

Plasați un exemplu

Variabilele necesare pentru aplicație sunt anunțate. Partition_information_ex este o structură care descrie informațiile despre secțiunea hard disk.

typedef Struct (

) Partition_information_ex;

În această parte a programului, funcția CreateFilea este chemată să primească un manipulator, care este scris în variabila HDevice.

Funcția Devioconlol este numită sincron. Ea este transmisă:

descriptor;

Codul ioctl ioctl_disk_get_partition_info_ex;

indicatorul la tamponul de intrare, nul în cazul nostru;

dimensiunea tamponului de intrare;

index pe tamponul de ieșire;

dimensiunea tamponului de ieșire;

pointer la variabila de tip DWORD în care numărul de octeți returnați va fi stocat;

indicatorul la structura suprapusă, care este utilizat pentru un apel de funcția asincronă.

După returnarea controlului, în cazul finalizării cu succes a funcției, în structura partiției_information_ex, secțiunea este stocată.

Analiza și ieșirea se fac. Înainte de a reveni la gestionarea sistemului de operare, puteți închide descriptorii deschisi. Acest lucru vă permite să faceți funcția CloseHandle (__ în mâner). Dacă descriptorii nu se închid, atunci acest lucru va face sistemul de operare pentru dvs.

2. Efectuarea cursurilor

2.1 Pasul 1.

Sarcina: 1. Dezvoltați un driver de kernel cu acces la porturi, efectuând acțiuni în funcție de opțiune și ieșirea de informații în fereastra de vizualizare de depanare (opțional), precum și o aplicație care rulează șoferul.

Listarea kurs_test.cpp.

#Include "stdafx.h"

#Include "Windows.h"

#include "stdlib.h"

SC_HANDLE HSCMANager;

SC_HANDLE HERVICE;

char acdriverpath;

dacă (HSCManager! \u003d 0) (

// Înregistrarea jucătorului în tabelul dispecerului scanager

dacă (homice! \u003d 0) (

// Ștergeți înregistrarea driverului

DELETESERVICE (HERVICE);

CloseServiceHandle (HService);

retur 0;

}

Listarea beeper.sys.

#Include.

#Define timer_frequency 1193167 // 1,193,167 Hz

#Define pitch_c 523 // 523,25 hz

#Define pitch_Cs 554 // 554,37 Hz

#Define pitch_d 587 // 587,33 Hz

#Define pitch_ds 622 // 622,25 Hz

#Define pitch_e 659 // 659,25 hz

#Define pitch_f 698 // 698,46 hz

#Define pitch_fs 740 // 739,99 hz

#Define pitch_g 784 // 783,99 hz

#Define pitch_gs 831 // 830,61 hz

#Define pitch_a 880 // 880.00 hz

#Define pitch_as 988 // 987,77 hz

vOID DO_DELAY (INT TIME) (

long I, J;

pentru (i \u003d 0; i<=time*0xfffff; i++) {}

}

vOID DO_BIG_DELAY (INT TIME) (

Dot_delay (2 * timp);

}

void xylofon (int npitch) (

int ntone \u003d timer_frequenta / npitch

_asm (

mOV AL, 10110110B; // Înregistrarea unui cuvânt de control în 43h

oUT 43H, AL; // canalul de control al sunetului - Diagrama logică utilizând un tonator de tonuri și biți de porți controlate de software

mOV EAX, NTONE; // înregistrarea frecvenței recalculate în 42

out 42h, al; // senior

mov al, ah; // junior

out 42h, al

În Al, 61h; // Schimbați secvența de control - transformarea ultimilor biți pe unitate

; // biți 0 - permis de utilizare a difuzorului

; // bit 1 - Permisul de conectare Timer-2 la difuzor

sau al, 00000011b; Vorbitor pe.

out 61h, al

}

Dot_delay (0x7f);

_asm (

în Al, 61h

și al, 11111100b; Speaker off.

out 61h, al

}

}

Xylofon (pitch_c);

Xylofon (pitch_s);

Xylofon (pitch_s);

Xylofon (pitch_s);

Xylofon (pitch_s);

Xylofon (pitch_s);

Xylofon (pitch_s);

return stadiu_device_configuration_error;

}

2.2 Pasul 2.

Dezvoltați un driver de dispozitive virtuale care vă permite să efectuați acțiuni disponibile numai la nivelul zero a privilegiilor (în conformitate cu opțiunea) și apoi transferați rezultatele la aplicație la 3 niveluri de privilegiu pentru a le afișa pe ecran.

Aplicația afișează rezultatul în fereastra standard Windows.

Listarea shablon.c.

#Include. // Diverse definiții NT

#Include.

Unicode_string g_usdevicename;

Unicode_string g_ussymboliklinkLinklink;

vOID DriverLOloaload (în Pdriver_Object Pdriverbject) (

Iodeletesymbollink (& g_ussymbolicLinkname);

Iodeletedevice (PDriverBject-\u003e DeviceObject);

}

NTSTATUS DISPTACHCREATELLOSE (PDEVICE_OBJECT PDEVICEOBJECT, PIRP PIRP) (// MJ_CREATE MJ_CLOSE Prelucrare

pirp-\u003e Iostatus.status \u003d Status_success;

pirp-\u003e Iostatus.information \u003d 0;

Iocompleterequest (Pirp, io_no_increment);

retur Staty_success;

}

Ntstatus DischatchControl (PDEVICE_OBJECT PDEVICEOBJECT, PIRP PIRP) (// prelucrare irp_mj_deviceControl

Ntstatus status;

int regesi;

// luați un pointer la io_stack_locație, în el pe iocontrolcode

dacă (Pirp-\u003e Tail.Overlay.CurrentStackLocation-\u003e parametri.deviceiocontrol.iocontrolcode \u003d\u003d ioctl_get) (

// comparați codul acțiunii și dacă este clientul nostru, atunci:

_asm (

mOV EAX, 0

mOV AL, 10H

out 70h, al

în al, 71h

cBW.

cwde.

mov Regesi, EAX

}

// aceasta este funcționalitatea noastră - luăm conținutul registrului ESI

// scrieți-l la tamponul de sistem

* ((int *) Pirp-\u003e asocirp.systembuffer) \u003d Regei;

pirp-\u003e Iostatus.information \u003d 4; // și setați dimensiunea rezultatului

stare \u003d status_success;

) Altceva stare \u003d stare_invalid_device_request;

pirp-\u003e Iostatus.Status \u003d Status;

Iocompleterequest (Pirp, io_no_increment);

retur (statutul);

}

int diverrentry (în Pdriver_Object Pdriverrobject, în Pusricode_String PusregisterPath) (

Ntstatus status;

Pdevice_object pdeviceobject;

// inițializați rândurile Unicode

Rtlinitunicodesting (& g_usdevicename, l "\\\\ dispozitiv \\\\ devget");

Rtliniticodestring (& g_ussymboliklinkname, l "\\\\? \\\\ sldevget");

// umpleți obiectul șoferului - explicați inteligent șoferul care conține procesele

pdriverrobject-\u003e DriverLOloaload \u003d

pdriverrobject-\u003e Majorfuncționalitate \u003d

pdriverrobject-\u003e Majorfuncționalitate \u003d

pdriverrobject-\u003e Majorfuncționalitate \u003d

// Creați un obiect logic al unui dispozitiv virtual

Stare \u003d IocreateLevice (Pdriverrobject, 0, & g_usdevicename, file_device_unknown, 0, fals, & pdeviceobject);

dacă (! Nt_success (stare)) (starea de retur;)

// Creați o legătură simbolică la dispozitiv

Stare \u003d IocreatesymbolicLink (& g_ussymbolicLinkname, & g_usdevicename);

dacă (! Nt_success (status)) (

Iodeletedevice (pdeviceobject);

starea de returnare;

}

starea de returnare;

}

Curs de listare2.cpp.

#Include "stdafx.h"

#Include "Windows.h"

#include "stdlib.h"

#Define ioctl_get ctl_code (file_device_unknown, 0x800, metoda_buffed, file_read_access + file_write_access)

int _tmain (int argc, _tchar * argv) (

Manipulați hdevice;

Bool devcontrol;

Dword dwbyetesreturned;

char Stroka;

/*

Parametrii:

lPFILENAME Adresa șirului de scor null care definește numele obiectului pentru ao crea sau a fi deschis.

dwdesireAccess tip de marfă la obiect. Acest parametru poate lua orice combinație a următoarelor valori:

Adică: Descriere:

0 Definește o cerere de disponibilitate a unui obiect pe dispozitivul specificat. Aplicația poate solicita atributele dispozitivului, fără acces la acesta.

Generic_read definește accesul la citire din obiect. Datele pot fi citite din fișier și indicatorul de fișiere poate fi mutat. Combinați cu generic_write pentru a accesa citirea.

Generic_write definește accesul la un obiect. Datele pot fi înregistrate într-un fișier și un indicator de fișiere poate fi mutat. Combinați cu generic_read pentru a accesa citirea.

dWSHAREMODE Modul de acces partajat la obiect. Cu valori zero, obiectul nu poate fi utilizat cu mai multe programe. Toate operațiile ulterioare de funcționare ale obiectului vor eșua până când descriptorul obiectului nu este închis. Pentru a partaja obiectul, utilizați o combinație a următoarelor valori:

Adică: Descriere:

File_Share_delete permite o secvență de operații deschise obiect pentru a solicita accesul la eliminare.

File_Share_read permite o secvență de operații de deschidere pentru a solicita citirea accesului.

File_Share_Write permite o serie de operații de deschidere pentru a solicita o intrare

lPSecurityAttribute adresa structurii Security_Attributes, care determină dacă descriptorul returnat de funcție ar trebui sau nu să fie moștenit de un proces copil.

Dacă ecranul de ecran este egal cu NULL, descriptorul nu poate fi moștenit.

dWCREATIONDISPOSITION

Adică: Descriere:

Create_always creează un nou fișier, întotdeauna.

Dacă fișierul există, funcția suprascrie fișierul.

Creați_new creează un fișier nou. Funcția va fi completă cu o eroare dacă fișierul există.

Open_always Deschideți fișierul, întotdeauna. Dacă fișierul nu există, funcția îl creează în același mod în cazul în care dwcreationdispoziția ar fi creată_NEW.

Open_existing deschide fișierul. Funcția va fi completată cu o eroare dacă fișierul nu există.

Truncate_existing deschide fișierul și îl taie la dimensiunea zero. Funcția va fi completată cu o eroare dacă fișierul nu există.

dWFLASADADADTRIBUTE Steagurile și atributele de fișiere.

Când se deschide un fișier existent, CreateFile ignoră fișierul șablonului.

Valori de returnare:

Dacă funcția are succes, mânerul deschis al fișierului specificat este returnat. Dacă fișierul specificat există înainte de a apela funcția și parametrul DWCREATIONSPOSITION este egal cu crearea_always sau open_always, apelul getLasterror va returna error_already_exists, chiar dacă funcția are succes. Dacă fișierul nu există înainte de a apela, GetLastterror va returna 0 (zero).

În caz de eroare, funcția va returnaval_handle_value. Pentru mai multe informații despre erori, apelați GetLastTerror.

*/

dacă (hdevice! \u003d 0) (

/*

hDevice este un mâner, construit "ohm-ul CreateFile.

dwiocontrolCode este o valoare care specifică opac care trebuie executată.

lPINBUFFER este un buffer adeziv, care este furnizat de datele necesare pentru a efectua operația specificată în DWIOCONTRODELECODE. Dacă opeararea nu atrăgă date, puteți muta null.

ninbuffesize este un PAZMP în octeți de date din buchet, pe care lpinbuffer specifică pe care.

lPOUTBUFFER este un buffer adeziv, care va fi eliberat de ieșire atunci când opamentul este cu succes proscat. Dacă opeararea nu specifică ieșirea, acest câmp ar trebui să fie nul "y.

nOUTBUFFERSIZ este un PAZMP în ocoleul cupă, pe care l-au subliniat LPOUTBUFFER la care.

lPBYTETERTURNED - ADPES OF TIPUL PEDIGREE DWORD, care va primi date despre datele incluse în LPOUTBUFFER.

lPOverLapped este un STPPP suprapad, dacă doriți ca operațiunea să fie Asynchon. Dacă doriți să așteptați până când PO este executat, plasați null în acest câmp.

*/

wSPrintf ((LPSTR) Stroka, "% x", adwoutbuffer); // Înregistrați șirul în tampon (Adwoutbuffer -\u003e Stroka)

CloseHandle (HDevice);

retur 0;

}

programul de calculator principal al șoferului

2.3 Pasul 3.

Curs de listare.cpp.

#Include.

#Include.

#Include.

{

Dword junk;

0, // Atribute fișiere

Întoarcerea (falsă);

}

0, // Dimensiunea tamponului de intrare

CloseHandle (HDevice);

retur (bresult);

}

int principal (int argc, char * argv)

{

/*

typedef Struct (

Partiția_style partiție; // Formatul secțiunii

Large_integer Highoffset; // deplasarea secțiunii START

Lungimea de partiție mare_integer; // Secțiunea de dimensiune

DWORTS PartitionNumber; // Numărul secțiunii

Boolean Rewritepartition; // Dacă secțiunea este suprascrisă adevărată

uniunea (

Partiție_information_mrb MBR; // Informații suplimentare Secțiunea de stil MBR

Partition_information_gpt GPT; // Informații suplimentare Partiția de stil GPT

};

) Partition_information_ex;

*/

Bool Bresult;

sistem ("pauză");

return ((int) bresult);

}

2.4 Pasul 4.

1) Combinați toate funcționalitățile proiectate în pașii 1-3, într-un complex de program.

Complexul final ar trebui să arate astfel:

- Driverul nostru este încorporat în sistem și încărcat la etapa de boot Windows.

- Aplicația solicită driverului pentru driverul (specificat în etapa 2), conducătorul auto transmite aceste informații, iar difuzorul se aprinde și pentru o vreme și melodia este redată (specificată la pasul 1). Apoi, aplicația necesită un driver către un sistem existent în sistem (în conformitate cu opțiunea la pasul 3).

2) Faceți o notă explicativă în care trebuie descrise toate cele 4 etape, precum și informații teoretice pentru fiecare etapă.

#Include "stdafx.h"

#Include "Windows.h"

#include "stdlib.h"

#Define ioctl_get ctl_code (file_device_unknown, 0x800, metoda_buffed, file_read_access + file_write_access)

Bool Getpartitionnumber (partiție_information_ex * PEX)

{

Manipulați hdevice; // descriptorul dispozitivului care este verificat

Bool Bresult; // Caseta de bifat

Dword junk;

hdevice \u003d createFile (text ("\\\\\\\\\\. \\\\ C:"), // dispozitive deschise

Generic_read | Generic_write, // acces la dispozitiv

File_Share_read | File_Share_Write, // Modul de partajare

Null, // atribute de securitate în mod implicit

Deschide_existing, // locație

0, // Atribute fișiere

Nul); // Nu copiați atributele de fișiere

dacă (hdevice \u003d\u003d invalid_handle_value) (// nu poate deschide dispozitivul

printf ("CreateFile () eșuat! \\ N");

Întoarcerea (falsă);

}

bresult \u003d DeviceIocontrol (HDevice, // dispozitivul solicitat

Ioctl_disk_get_partition_info_ex, // Funcționare

Null, // pointer la tamponul de intrare

0, // Dimensiunea tamponului de intrare

pEX, Sizeof (* PEX), // tampon de ieșire

& junk, // Numărul de octeți returnați

(LpoveLapped) null); // sincronizare I / O (I / O)

CloseHandle (HDevice);

retur (bresult);

}

int _tmain (int argc, _tchar * argv) (

SC_HANDLE HSCMANager;

SC_HANDLE HERVICE;

char acdriverpath;

Manipulați hdevice;

Bool devcontrol;

Dword dwbyetesreturned;

LPVOID Adwinbuffer, Adwoutbuffer;

char Stroka;

Partition_information_ex PEX; // structura dispozitivului

Bool Bresult;

hdevice \u003d createFile ("\\\\\\\\\\. \\\\ sldevget", generic_read + generic_write, 0, nul, deschide_exist, 0, null);

dacă (hdevice! \u003d 0) (

DevControl \u003d Devidiocontrol (HDEVICE, IOCTL_GET, & ADWINBUFFER, DIMENSOF (ADWINBUFFER), & ADWOUFFFER, DIMENSOF (ADWOUFFFER), DWBYTESTETURED, NULL);

dacă ((devcontrol! \u003d 0) && (dwbytesreturned! \u003d 0)) (

wSPrintf ((LPSTR) Stroka, "% x", adwoutbuffer); // Înregistrați șirul în tampon (Adwoutbuffer -\u003e Stroka)

dacă (Stroka \u003d\u003d "00000100") Messagebox (Null, "găsit 1.44 MB", "Yermakov FDD scaner", MB_OK);

alt mesaj (Null, "nu a fost găsit", "Yermakov FDD scaner", MB_OK);

hSCMANAGER \u003d OpenscMager (Null, Null, SC_MANAGER_CREATE_Service);

dacă (HSCManager! \u003d 0) (

Getfullpathname ("Beeper.sys", dimensiunea acdriverpath, acdriverpath, null);

// Înregistrarea muzicianului în tabelele SCM

hsrvice \u003d CreateService (HSCManager, "Beeper11", "Nice Melody Beeper11",

Service_start + delete, service_kernel_driver, service_demand_start,

Service_error_rignore, acdriverpath, , , , , null);

dacă (homice! \u003d 0) (

StartService (HANT, 0, NULL);

DELETESERVICE (HERVICE);

CloseServiceHandle (HService);

) Alt mesaj (Null ", poate" driverul de înregistrare ", , mb_iconstop);

CloseServiceHandle (HSCManager);

) Alt mesaj de mesaj (null ", se poate conecta la scanager", , mb_iconstop);

) Alt mesaj de mesaj (null ", poate trimite codul de control", , mb_ok);

CloseHandle (HDevice);

) Alt mesaj (Null ", Dev nu este prezent", , mb_iconstop);

bresult \u003d getpartitionnumber (& PEX);

dacă (Bresult) (Printf ("partițienumber \u003d% d \\ n", PEX.Partitionnumber);

) Altfel (Printf ("GetPartitionnumber () a eșuat. Eroare% d. \\ N", GetLasterror ());)

sistem ("pauză");

return ((int) bresult);

}

3. Cerere de locuri de muncă

Figura 3.1. Driver de la pasul 2

Figura 3.2. Pasul 3 Driverul

Postat pe Allbest.ru.

Documente similare

Mecanisme pentru interacțiunea modului de kernel și aplicarea utilizatorului: arhitectura motorului multistrat, algoritmul de ascundere a datelor, driverul și interacțiunea aplicațiilor, interfața cu utilizatorul pentru accesul la fișiere la fișiere.

lucrări de curs, a fost adăugată 06/23/2009


Arhitectura Windows NT I / O. Organizația internă de autobuz USB. Caracteristicile esențiale ale modelului de acționare WDM. Puncte de conectare a driverului dezvoltat, plasarea codului în memorie, instalarea driverului în sistem. Implementarea codului de conducere în C.

cursuri, a adăugat 09/27/2014


Structura modului de utilizator care oferă posibilitatea de a utiliza utilizatorul pentru a interacționa cu sistemul. Descrierea modului kernel, care asigură executarea sigură a aplicațiilor (programelor) utilizatorului. Abstracția hardware Windows NT.

prezentare, adăugată 23.10.2013


Windows 98 Kernel. Rolul modulelor de kernel pe 16 biți. Probleme de performanță. Cooperativă și deplasare multitasking. Utilizarea resurselor îmbunătățite în Windows 98. Folosind WordArt. MS Outlook Express: Crearea și trimiterea de mesaje.

examinare, adăugată 14.04.2005


Funcționarea în comun a tuturor dispozitivelor de calculator și accesul la resursele sale. Conceptul și funcția sistemului de operare grafică Windows. Windows Help Desk. Gestionarea sistemului de fișiere. Tehnologie "Plug and Play". Interfață grafică Windows.

lucrări de testare, a fost adăugată 01/22/2011


Caracteristicile sistemului de operare. Istoria dezvoltării ferestrelor. Versiune comparativă a versiunilor Windows. Elemente și instrumente Windows XP. Programe de aplicație în Windows XP. Calculatoare de desktop și laptop care rulează ferestre.

raport, a adăugat 10/16/2011


Utilizarea driverului modului de kernel și aplicația de control pentru crearea firelor de sistem. Imitație de prelucrare a datelor și organizarea întârzierilor. Dezvoltați un driver în C ++. Configurarea bancului de testare. Precizia schimbării întârzierilor și a temporizatorului.

lucrări de curs, a fost adăugată 24.06.2009


Domilіzhenna Structura ferestrelor interne. Arhitectura NT і Structura kernel-ului. Metode de reconstrucție a funkii la regimul kernelului regimului de naștere. Subestimați șoferul. Pachet de intrare-villode. Otsіnka Stab_lnosti TU Beepes Windows Systems.

cursuri, adăugat 02.01.2014


Concept, tipuri și lucrări de firewall. Built-in Firewall Windows. Windows XP SP2, acces la setările Windows XP Service Pack Firewall 2. Windows Vista, a permis traficul. Windows 7, Setări pentru profiluri active. Firewall personal, niveluri de testare.

rezumat, a adăugat 11/19/2010


Cunoștință cu caracteristicile tehnice ale unui computer personal. Instalarea sistemului de operare și a driverelor Windows 7. Metode de curățare Windows XP Professional SP3. Metode de restabilire a sistemului de operare. Efectuarea Microsoft Office 2010.

Microsoft în sistemul de operare Windows 10 acordă o atenție deosebită siguranței. Unul dintre elementele importante ale sistemului este "apărătorul Windows", dar este capabil să facă față tuturor amenințărilor. În special, câștigă recent o prevalență specială a virușilor de ransomware, cele mai renumite reîncarnări ale căror programe rău intenționate ale Petya și. Microsoft a implementat în Windows 10 Izolarea kernelului și integritatea memoriei care vizează combaterea virușilor de ransomware. În mod implicit, acestea sunt dezactivate.

Cuprins:

Ce este izolarea kernelului și integritatea memoriei

Izolarea kernelului - Acesta este un proces de protecție suplimentar, care este furnizat prin metoda de a gardiza procesele de calculator din sistemul de operare și dispozitivul. Datorită acestor acțiuni, este posibil să se evite subminarea funcționării sistemului de operare atunci când virușii de pe computer au lovit.

Integritatea memoriei - Aceasta este o izolare concomitentă a funcției de protecție centrală, care vizează limitarea accesului de la programe potențial periculoase necunoscute la procese la nivel înalt.

IMPORTANT: Funcția de izolare a kernelului poate funcționa numai dacă există condiții suficiente pentru acest lucru din partea hardware-ului de calculator. În setările BIOS, tehnologia de virtualizare ar trebui să fie activă, în detrimentul căruia computerul Windows 10 poate rula diverse aplicații într-un container virtual, limitând accesul componentelor cheie ale sistemului.

Cum să activați izolația kernelului și integritatea memoriei

Parametrii sistemului de operare Windows 10 vă permit să gestionați complet funcțiile de securitate pe un computer. Prin setările Windows 10, puteți activa izolația kernelului și integritatea memoriei după cum urmează:

După cum sa menționat mai sus, dacă componenta hardware a computerului nu acceptă posibilitatea virtualizării, această funcție nu va funcționa. Când porniți utilizatorul va vedea mesajul din colțul din dreapta jos. "Imposibil de asigurat integritatea memoriei. Posibilă incompatibilitate. " Dacă apare acest mesaj, este recomandat să mergeți la BIOS și să vedeți dacă funcția Secure Boot este activată (modul de boot).

Cum să dezactivați izolația kernelului și integritatea memoriei

Noi caracteristici în sistemul de operare care afectează în mod serios munca sa, riscă întotdeauna să devină cauza problemelor atunci când lucrează. Fără excepție și funcția de izolare a kernelului. Utilizatorii care au încercat deja, sărbătoresc pe Forumurile Microsoft, care se confruntă cu probleme atunci când rulează o serie de jocuri și programe. Singura modalitate de a rezolva această problemă este de a dezactiva funcția de izolare a kernelului și integritatea memoriei. Poate că în viitoarele actualizări, dezvoltatorii de aplicații sau Microsoft vor corecta această incompatibilitate.

Există 3 moduri de a dezactiva izolația kernel-ului și integritatea memoriei:

Dispozitivul de distribuitor de pornire (manager de putere) Ochiul nu coboară din utilizarea energiei electrice pe tot parcursul sistemului. Din punct de vedere istoric, gestionarea consumului de energie a constat în deconectarea monitorului și oprirea rotației unităților. Dar această problemă devine tot mai dificilă - datorită cerințelor pentru o creștere a duratei laptopurilor din baterii, precum și considerente de economisire a energiei pe computerele desktop (care sunt permise incluse permanent) și costuri ridicate de către electricitatea consumată de server ferme.

Noile instrumente de gestionare a energiei includ reducerea consumului de energie pe componente atunci când sistemul nu este utilizat, pentru acest lucru, dispozitivele individuale comutați la starea de rezervă sau chiar complet deconectați (folosind comutatorul de alimentare). Sistemele multiprocesoare dezactivează procesoare individuale atunci când nu sunt necesare și chiar pot reduce frecvența ceasului procesorului (pentru a reduce consumul de energie). Atunci când procesorul este inactiv, consumul de energie scade, de asemenea, deoarece nu trebuie să facă nimic, cu excepția așteptării apariției întreruperii.

Windows suportă un mod special de oprire numită Hibernare (Hybernare), în care întreaga memorie fizică este copiată pe disc și apoi consumul de energie este redus la minim (în sistemul de laptopuri de hibernare poate funcționa timp de săptămâni), în timp ce bateria este taxat minim. Deoarece întreaga stare de memorie este înregistrată pe disc, puteți chiar să înlocuiți bateria laptopului (în timp ce este în hibernare). Când sistemul își reia munca, lăsând hibernarea, restabilește starea de memorie salvată (și reinlificizează dispozitivele). Acest lucru aduce computerul la aceeași stare în care a fost în fața hibernării (fără a trebui să se înregistreze și să ruleze toate aplicațiile și serviciile care au fost executate. Windows încearcă să optimizeze acest proces, ignorând paginile nemodificate (având o redundanță disc) și comprimă paginile de memorie de repaus pentru a reduce algoritmul I / O necesar. Algoritmul de hibernare asigură o lățime de bandă automată a sistemului I / O și a procesorului bandwosted. astfel încât, cu o lățime de bandă mai mare a procesorului, reduce nevoia unui transfer de sistem I / O, este utilizată mai multă resursă intensivă, dar mai eficientă. Compresia datelor. O lățime de bandă suficientă a sistemului I / O vă permite să evitați compresia atunci când utilizați modul de hibernare. Când utilizați multiprocesoarele de ultimă generație, intrarea în starea de hibernare și ieșire din ea poate fi doar câteva secunde, chiar dacă operația poate fi Sistemele au un volum mare.

Alternativa de hibernare - modul de așteptare, în care managerul de putere traduce întregul sistem la cea mai mică stare de consum de energie (exact atât de multă energie, după cum este necesar pentru regenerarea stării dinamice a memoriei). Deoarece memoria nu trebuie copiată pe disc, atunci trecerea la această stare pe unele sisteme este efectuată mai repede decât hibernările.

În ciuda disponibilității hibernării și a așteptărilor, mulți utilizatori nu au scăpat de obiceiul de a-și transforma computerul personal la sfârșitul muncii.

Hibernationul este utilizat în Windows pentru a implementa pseudo-treptele de la început, numit Hiberboot, care se efectuează mult mai repede decât închiderea și lansarea obișnuită. Când utilizatorul oferă sistemului, Hiberboot afișează utilizatorul din sistem și apoi îl traduce în starea de hibernare la acel punct cu care va fi posibil să vă conectați din nou. Mai târziu, când utilizatorul pornește din nou sistemul, Hiberboot va relua funcționarea sistemului din punctul de intrare al utilizatorului. Pentru un utilizator, toate acestea arată ca o oprire foarte rapidă, deoarece majoritatea etapelor de inițializare a sistemului sunt sărite. Desigur, uneori sistemul trebuie să fie dezactivat cu adevărat pentru a elimina problemele sau a seta actualizarea kernelului. Dacă sistemul primește o comandă de repornire și nu la oprire, transferă această oprire și efectuează sarcina obișnuită.

Este de așteptat ca dispozitivele de calcul pe telefoane și computerele tabletelor, precum și pe noile generații de laptopuri, vor consuma întotdeauna o cantitate mică de energie electrică. Pentru a asigura un astfel de mod, în Windows Modern a implementat o versiune specială a managementului alimentării, care se numește CS (în așteptare în așteptare pentru modul de conectare). CS este posibil pe sistemele cu echipament special de conectare la rețea capabil să urmărească traficul într-un set mic de conexiuni, folosind mult mai puțină energie decât atunci când procesorul central este operațional. Se pare că sistemul CS este întotdeauna activat, ieșirea din CS este efectuată imediat imediat ce utilizatorul a pornit pe ecran. Așteptarea în modul de conectare este diferită de modul de așteptare obișnuit, deoarece sistemul CS va ieși din așteptarea când primește un pachet din conexiunea monitorizată. După ce bateria începe să se așeze, sistemul CS intră în starea de hibernare pentru a evita descărcarea completă a bateriei și posibila pierdere a datelor utilizatorului.

Realizarea activității bateriei necesită nu numai așa de descărcarea procesorului. De asemenea, este important cât mai mult posibil pentru a ține procesorul în starea off. Echipamentul de rețea de sistem CS permite procesatorilor să rămână înainte de primirea datelor, dar recrutarea procesorului poate fi cauzată de alte evenimente. Driverele de dispozitive Windows bazate pe NT, serviciile de sistem și aplicațiile în sine sunt adesea lansate fără un motiv special, doar pentru a verifica starea de cazuri. O astfel de activitate de studiu se bazează de obicei pe setările temporizatorului pentru codul de pornire periodică în sistem sau aplicație. Un sondaj bazat pe semnalele temporizatorului poate face o sarcină în evenimente, inclusiv un procesor. Pentru a evita acest lucru în ferestrele moderne de la astfel de cronometre, trebuie să specificați parametrul de eroare care permite sistemului de operare să combine evenimentele temporizatorului și să reducă numărul de baze individuale pentru a porni procesorul. Windows este, de asemenea, întocmită condițiile în care aplicația care nu este în stadiul executării active poate efectua codul în fundal. Operațiile, cum ar fi verificarea actualizărilor sau conținutul revigorant, nu pot fi efectuate numai la începutul expirării temporizatorului. Cererea trebuie să respecte sistemul de operare în materie de activitate de fond. De exemplu, verificarea actualizărilor ar trebui să aibă loc doar o dată pe zi sau data viitoare când bateria va apărea pe dispozitiv. Un set de mediatori de sistem oferă diferite condiții care pot fi utilizate pentru a limita activitatea de fond. Dacă sarcina de fundal necesită acces la o rețea ieftină sau la puteri personalizate, intermediarii nu vor îndeplini sarcina până când nu vor apărea condițiile necesare.

Astăzi, multe aplicații sunt implementate atât cu un cod local, cât și cu servicii în nor. Windows oferă servicii de notificare Windows (Serviciul de notificare Windows (WNS), permițând servicii terțe să împingă notificările către dispozitivul Windows din CS fără a solicita echipamente de rețea CS să asculte special pachetele de pe servere terță parte. Notificările WNS pot notifica evenimentele critice de timp, cum ar fi un mesaj text sau un apel VoIP. Atunci când pachetul WNS este primit, procesorul va trebui să îl pornească pentru procesare, dar echipamentul de rețea CS are capacitatea de a distinge între traficul de conexiuni diferite, ceea ce înseamnă că procesorul nu ar trebui inclus ca răspuns la fiecare pachet arbitrar provenind de la interfața de rețea.