OS Windows - Registr

Termíny big endian, little endian, případně middle endian označují způsob ukládání vícebajtových dat v operační paměti. V případě celých čísel se jedná o pořadí jednotlivých bajtů, které obsahují hodnotu daného čísla. V případě little endian jsou jednotlivé bajty dat ukládány v pořadí od nejméně významného po ten nejvýznamnější. Například číslo 0x80543A02 bude ve formátu little endian do operační paměti zaznamenáno v sekvenci bajtů 0x02 0x3A 0x54 0x80. Číslo je tedy v paměti uloženo „obráceně“. Tento formát ukládání dat používají i procesory Intel.

Naproti tomu, formát big endian ukládá data od nejvýznamnějšího bajtu po ten nejméně významný. V tomto případě by číslo 0x80543A02 reprezentovala sekvence bajtů 0x80 0x54 0x3A 0x02. Pořadí bajtů je podobné pořadí cifer psaných na papír. Obdobným pravidlům také podléhá pořadí ukládání jednotlivých bitů v jednom bajtu. V případě little endian každý bajt začíná nejméně významným bitem (obvykle označovaným jako bit 0) a končí tím nejvýznamnějším (například bit 31, nebo bit 63; záleží na velikosti datového typu). Kromě výše zmíněných forem ukládání bajtů dat v pořadí od toho nejvýznamnějšího k nejméně významnému existují i formy, které jednotlivé bajty ukládají ještě v jiném pořadí. Nazývají se middle endian nebo mixed endian.

Windows API obsahuje řadu funkcí, jejichž jména začínají prefixem Reg a které aplikacím umožňují číst a manipulovat jak s jednotlivými klíči a hodnotami, tak i s celými podstromy. Mnoho z nich funguje tak, že pro úspěšné provedení operace požadují cestu k cílovému klíči. Tato cesta je relativní k jinému klíči, ke kterému již aplikace musí vlastnit handle.

Pro vytvoření nového klíče slouží funkce RegCreateKeyEx, jejíž definici vidíte na výpisu 1 Na rozdíl od funkcí pro tvorbu jiných druhů objektů jádra tato rutina nevrací handle v návratové hodnotě, ale přes výstupní parametr phkResult. V případě funkcí určených pro práci s registry slouží návratová hodnota k předání chybového kódu.

Potřebuje-li aplikace vytvořit v určitém místě stromu registru nový klíč, musí mít přístup k některému z klíčů, které se nacházejí na cestě od kořene stromu k novému objektu. Handle předané v prvním parametru (hKey) spolu s relativní cestou předanou v parametru lpSubKey jednoznačně určuje polohu klíče ve stromu registru. Pokud takový objekt již existuje, funkce se místo vytvoření k němu pokusí získat zadaný přístup. Obdobným způsobem funguje většina rutin sloužících pro vytvoření jiných druhů objektů jádra.

Hodnotou parametru dwOptions může volající nastavit některé specifické vlastnosti nového klíče. Hodnota REG_CONTROL_CREATE_LINK vytvoří klíč plnící roli symbolického odkazu v rámci registru. Data hodnoty s názvem SymbolicLinkValue jsou následně interpretována jako cíl tohoto odkazu. Cílová cesta musí být absolutní.

Další zajímavou možnost skýtá příznak REG_CONTROL_VOLATILE, který jádru systému říká, že nový klíč bude žít pouze v paměti a nebude ukládán do souborů registru na pevný disk, a tedy ani nepřežije restartování systému. Takové klíče se také označují jako volatilní.

Třetí možnou hodnotou parametru dwOptions je REG_CONTROL_BACKUP_RESTORE, kterou lze použít pouze v případě, že první dva parametry volání RegCreateKeyEx odkazují již na existující klíč. Nastavením této hodnoty aplikace jádru sděluje, že bude daný klíč zálohovat či obnovovat. Pokud má k danému úkonu práva, jádro ke klíči vytvoří handle s dostatečným oprávněním, ačkoliv popisovač zabezpečení klíče uživateli, pod kterým aplikace běží, taková oprávnění získat nedovoluje.

Pokud aplikace vytváří nový klíč nebo nechce obsah již existujícího klíče obnovit či zálohovat, určuje hodnotou parametru samDesired, která oprávnění chce přiřadit handle, jež bude v případě úspěchu nový (či již existující) klíč reprezentovat. Oprávnění dovolují klíčem provádět další operace, mezi které patří například vytváření podklíčů nebo čtení a modifikace hodnot. Seznam všech možných oprávnění a jejich význam ukazuje tabulka 3.

Poslední argument (lpdwDisposition), též výstupní, po dokončení volání funkce určuje, jaká operace byla ve skutečnosti provedena. Může nabývat hodnot REG_CREATED_NEW_KEY (byl vytvořen nový klíč), nebo REG_OPENED_EXISTING_KEY (podařilo se získat handle k již existujícímu klíči).

Zbylé parametry umožňují nastavit název třídy nového klíče a jeho popisovač zabezpečení.

Pokud program ví, že nějaký klíč existuje a potřebuje k němu získat přístup, může použít rutinu RegOpenKeyEx, jejíž definici ukazuje výpis 2. Význam jejích argumentů odpovídá stejně pojmenovaným parametrům funkce RegCreateKeyEx, jen parametr ulOptions může nabývat pouze hodnoty REG_CONTROL_BACKUP_RESTORE, která má význam jako v případě argumentu dwOptions rutiny z 1.

Pokud již aplikace nepotřebuje pracovat s klíčem, jehož handle získala pomocí užití jedné z výše popsaných funkcí, měla by jej zrušit voláním rutiny RegCloseKey. Její definici ukazuje výpis 3. Rutina jako svůj jediný klíče akceptuje hodnotu handle, které chce aplikace zrušit.

Stromová struktura registru je uložena v několika souborech na pevném disku. Operační systém při svém startu tyto soubory vyhledá a vytvoří z nich stromovou strukturu. Windows API dovoluje převádět jednotlivé podstromy registru do souboru a opačným směrem. K tomuto účelu slouží funkce RegSaveKey, RegLoadKey, RegUnLoadKey, RegReplaceKey a RegRestoreKey.

Rutina RegSaveKey (viz výpis 9) umožňuje uložit část stromu registru do souboru. První parametr udává handle klíče, který bude sloužit jako kořen ukládaného podstromu. Druhým parametrem volající určí název souboru a třetím jeho popisovač zabezpečení.

Formát vzniklého souboru umožňuje ovlivnit rozšíření předchozí rutiny v podobě funkce RegSaveKeyEx. Ta přidává parametr Flags, který svoji hodnotou ovlivňuje formát vzniklého souboru následujícím způsobem:

LONG WINAPI RegSaveKeyEx( in HKEY hKey, in LPCTSTR lpFile, in_opt LPSECURITY_ATTRIBUTES lpSecurityAttributes, in DWORD Flags); ---

Načíst podstrom ze souboru zpět do registru je možné hned třemi způsoby. Liší se poškozením existujícího stromu, které mohou způsobit.

Nejméně invazivní metoda spočívá v použití rutiny RegLoadKey (výpis 10), která umožní připojit kořen nového podstromu jako nový podklíč kořene HKLM nebo HKU. Ke změnám ostatních částí stromu tedy nedochází. První dva parametry slouží k určení jednoho ze dvou kořenů a názvu podklíče, který bude tvořit kořen nově připojeného podstromu. Třetí argument určuje název souboru, jehož obsah bude interpretován jako strom klíčů s jejich hodnotami.

Protipól k RegLoadKey tvoří funkce RegUnLoadKey, která odstraní ze stromu registru podstrom, jehož kořenem je podklíč některého ze dvou výše zmíněných kořenů HKLM a HKU. Rutinu lze s úspěchem použít pouze na podklíče připojené do registru pomocí jejího dvojčete.

Druhá možnost, jak změnit strukturu stromu registru, spočívá v použití funkce RegReplaceKey, kterou vidíte na výpisu 11. Tato rutina nejprve zjistí, v jakém souboru je uložen podstrom, do kterého patří klíč zadaný pomocí prvních dvou parametrů a tento soubor přesune do umístění zadaného čtvrtým parametrem. Následně přejmenuje soubor zadaný ve třetím parametru na jméno původního souboru, čímž je nahrazení podstromu dokončeno. Změna se projeví až po restartování systému.

Poslední možnost načtení podstromu ze souboru do registru spočívá v použití funkce RegRestoreKey (viz výpis 12). Tato rutina přepíše podstrom podklíče udaného parametrem hKey a jeho seznam hodnot podstromem načteným ze souboru s názvem uloženým v parametru lpFile.

Třetí parametr blíže specifikuje chování celého procesu. Nastavení příznaku REG_FORCE_RESTORE donutí systém k přepsání podstromu klíče i v případě, že do něho odkazují handle vlastněná některými procesy. Tím budou tato handle zneplatněna.

Aplikace též může specifikovat příznak REG_WHOLE_HIVE_VOLATILE čímž zajistí, že celý načtený podstrom se bude nacházet pouze v paměti a jeho změny nebudou ukládány na pevný disk. Při specifikování tohoto příznaku musí handle klíče odpovídat jednomu z kořenů HKLM nebo HKU.

Na rozdíl od RegLoadKey rutina RegRestoreKey nepřipojuje zadaný soubor do registru přímo, ale data z něho pouze překopíruje. Důsledkem tohoto chování je, že zadaný soubor s podstromem není po dokončení volání funkce zamčen proti přístupu ze strany aplikací.

Virtualizace registru umožňuje aplikacím nepřipraveným na prostředí Windows Vista a novějších verzí operačního systému zapisovat do některých klíčů registru, i když na provedení této akce nemají dostatečná oprávnění. Zápis se emuluje přesměrováním na klíč ve stromu z uživatelského profilu. Aby vše bylo transparentní, systém přesměrovává i pokusy o čtení.

Virtualizovány jsou jen klíče nacházející se ve stromu HKLM\SOFTWARE, ke kterým má administrátor právo zápisu. Výjimku tvoří větve HKLM\SOFTWARE\Classes, HKLM\SOFTWARE\Microsoft\Windows a HKLM\SOFTWARE\Microsoft\Windows NT.

Virtualizaci podléhají pouze interaktivní 32bitové aplikace, které nemají ve svém souboru manifest specifikován atribut requestedExecutionLevel. Služeb, ovladačů a 64bitových aplikací se virtualizace netýká.

Virtualizace se projevuje pouze při třech operacích: získávání handle ke klíči, čtení a modifikaci.

Pokud se aplikace pokusí získat handle s právem zápisu k virtualizovanému klíči, operace (na rozdíl od pokusu s normálním klíčem) neselže. Jádro vrátí handle s maximálním možným oprávněním, které může aplikace k danému klíči získat. Tuto tichou „úpravu“ volajícímu nijak nesignalizuje. Aplikace ji však může detekovat pomocí funkce NtQueryObject, která umožňuje zjišťovat o určitém handle (či objektu, na který toto handle odkazuje) různé informace včetně oprávnění.

Pokusí-li se aplikace do virtualizovaného klíče zapsat, ať již vytvořením podklíče, nebo nastavením dat nové či existující hodnoty, tato operace je přesměrována na klíč v oblasti HKU\ID_uživatele-Classes\VirtualStore\Machine\Software. Pokusí-li se program pod klíčem HKLM\SOFTWARE\ProgramX vytvořit hodnotu HodnotaY, virtualizace zajistí vytvoření hodnoty s daným jménem v klíči HKU\ID_uživatele\VirtualStore\Machine\Software\ProgramX. Přesměrování se provede i tehdy, obsahuje-li původní klíč ve stromě HKLM hodnotu HodnotaY. Virtualizovaná oblast má přednost před oblastí reálnou.

Třetí případ virtualizace se týká čtení obsahu klíče. Scénář se drží dvou pravidel:

Na rozdíl od virtualizace, vlastnost přesměrování se zaměřuje na zajištění soužití 32bitových a 64bitových aplikací na jednom operačním systému. Tato vlastnost se tedy projevuje pouze na 64bitových verzích Windows.

Lepší soužití je zajištěno oddělením přístupu 32bitových a 64bitových aplikací k důležitým klíčům registru. Volání rutin pro práci s registry provádí u 64bitových aplikací přesně to, co by každý očekával – pracuje přímo s objekty, o které volající pomocí předaných hodnot parametrů žádá. Operace prováděné 32bitovými aplikacemi jsou však, obdobně jako v případě virtualizace, v případě některých klíčů přesměrovány do podstromu HKLM\SOFTWARE\Wow6432Node. Na některé klíče, které jsou součástí podstromů, jež jsou přesměrovány, přesměrování uplatňováno není a jejich obsah je sdílen oběma druhy aplikací. Takové klíče se označují jako sdílené.

Seznam klíčů, na kterých je uplatňováno přesměrování, se liší v závislosti na verzi operačního systému. Konkrétní údaje najdete v tabulce.

Systém dává aplikacím při vytváření, získávání handle či mazání klíče na výběr, zda tuto změnu provést v podstromu nativním pro 64bitové, nebo 32bitové aplikace. Pokud program při volání některé z rutin RegCreateKeyEx, RegOpenKeyEx či RegDeleteKeyEx specifikuje příznak KEY_WOW64_32KEY (hodnota 0x0100), operace se provede v části transparentně přístupné 32bitovým aplikacím. Příznak KEY_WOW64_64KEY (hodnota 0x0200) zpřístupňuje i 32bitovým aplikacím nativní oblast pro programy 64bitové.

Přesměrování může způsobit komplikace při zjišťování seznamu podklíčů, protože při nepoužití výše zmíněných příznaků se volající v závislosti na platformě, pro kterou byl přeložen, dozví jenom část seznamu. Pro získání všech podklíčů je zapotřebí získat k jejich rodiči nejprve handle s jedním příznakem a poté i handle s druhým příznakem. Použití obou příznaků najednou není podporováno.

V tabulce se nachází i klíče, na které se uplatňuje třetí výše zmíněná vlastnost registru — reflexe. Projevuje se u některých klíčů a hodnot, jež sice patří do podstromu, na který systém uplatňuje přesměrování, ale jejichž obsah musí být stejný (konzistentní) jak pro 32bitové, tak 64bitové aplikace.

Konzistenci obsahu takových klíčů a hodnot zajišťuje Registr Windows synchronizací zápisů. Jakmile nějaký program změní obsah klíče, na který je uplatňována reflexe, a zruší na něj handle, systém překopíruje nový obsah i do druhé části registru tak, aby následující pokusy o jeho čtení z libovolné aplikace vydaly stejná data.

Z popisu synchronizace při reflexi vyplývá, že pokud více aplikací zapisuje do jednoho klíče s reflexí, projeví se akce pouze té entity, která jako poslední zruší ke klíči handle.

Stejně jako ostatní data a programy, i celý registr je na pevném disku uložen v jednotlivých souborech. Neexistuje žádný speciální prostor na diskovém oddílu, který by Windows vyhrazovaly pouze pro toto úložiště. Celý strom není nikdy uložen v jednom souboru, ale jeho části jsou rozesety jak v systémovém adresáři, tak v uživatelských profilech. V terminologii se každý soubor obsahující nějaký podstrom registru označuje jako hive.

Umístění jednotlivých souborů na disku a jejich zařazení do stromu registru vidíte v tabulce 7. Na rozdíl od předchozích částí kapitoly, kde se pro většinu podstromů používaly názvy jejich předdefinovaných handle, v tabulce vidíte jejich skutečná jména v rámci jmenného prostoru správce objektů.

Pro větší přehlednost je celý strom zachycen i na obrázku. Vidíte, že má ve skutečnosti pouze jediný kořen v podobě klíče \Registry , který se však nevyskytuje v žádném ze souborů a systém jej pokaždé vytváří během svého startu. Tento klíč má dva podklíče: Machine a User. Ty se také nacházejí pouze v paměti, ale na rozdíl od jejich rodiče již jsou vidět v Editoru registrů a lze k nim přistupovat přes předdefinované handle HKEY_LOCAL_MACHINE a HKEY_USERS.

Seznam aktuálně používaných souborů hive a jejich napojení do stromu registru systém ukládá v podobě klíče

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\hivelist

jehož každá hodnota reprezentuje jedno napojení. Její název určuje jméno klíče, který slouží k napojení a data obsahují název souboru hive. Ukázku obsahu tohoto klíče vidíte ve formě snímku Editoru Registru na obrázku. Obsah tohoto klíče se nikdy neukládá na pevný disk.

Každý hive tedy obsahuje údaje o jednom celém stromu klíčů a hodnot. Skládá se z hlavičky, jež se označuje jako základní blok (base block) obsahující různé všeobecné informace o daném stromu, mezi které patří interní jméno a umístění kořenového klíče, a množství datových bloků, v terminologii registru se každý z nich označuje jako hbin, jež obsahují strukturu celého podstromu včetně dat jednotlivých hodnot. Každý hbin se krom krátké hlavičky skládá z buněk (cell) různých typů. Každý typ buňky je určen pro uchovávání určitých dat – například údajů o klíči, o hodnotě či popisovači zabezpečení.

Základní blok zabírá vždy první čtyři kilobajty na počátku souboru každé hive. Jeho strukturu vidíte na výpisu 14.

Začátek bloku (pole Signature ) je označen magickou signaturou regf. V interních datových strukturách registru se podobné signatury používají velmi často.

Úlohou polí Sequence1 a Sequence2 je odrážet stav synchronizace obsahu hive v paměti a na pevném disku. Pokud obě tato pole obsahují stejnou hodnotu, struktura hive v paměti a na pevném disku je konzistentní, tedy obsahuje stejná data. Výjimku tvoří pouze klíče, které byly vytvořeny s příznakem, jež jádru diktuje uchovávat je pouze v paměti (volatilní klíče). Pokud se obsah polí liší, znamená to, že obsah hive v paměti je aktuálnější než data příslušného souboru na pevném disku.

Mezi významné položky patří také RootCell, která udává, kde se nachází buňka s údaji o kořenovém klíči hive. Tato informace je uložena ve formě offsetu počátku buňky od počátku prvního datového bloku (hbin). První datový blok začíná vždy ihned za koncem základního bloku.

Členy MajorVersion a MinorVersion obsahují číslo verze formátu souboru hive. Do doby psaní tohoto textu byly zpozorovány dvě kombinace hodnot. Soubory registru hive ve verzi 1.3 se používají až do Windows 2000. Novější verze operačního systému dávají přednost verzi 1.5, ale umějí pracovat i se starší verzí.

Velikost datové oblasti hive obsahuje položka Length. Jedná se o součet velikostí všech datových bloků. Interní jméno hive je uloženo v poli FileName a může dosáhnout maximálně délky 64 znaků. Integritu celého základního bloku hlídá kontrolní součet uložený v položce CheckSum.

Velikost datového bloku se pohybuje v násobcích 4 kilobajtů. Stejně jako v případě bloku základního, i ten datový uvozuje, v tomto případě velmi krátká, hlavička, jejíž definici vidíte na výpisu 15. Pole Signature zde obsahuje magickou hodnotu hbin. Každý datový blok dále zná svoji pozici v rámci hive (FileOffset) a velikost v bajtech (Size).

Za hlavičkou datového bloku následuje pole různě velkých buněk. Každá buňka na svém začátku obsahuje informaci o velikosti v podobě 32bitového celého čísla. Bit 31 této hodnoty se do velikosti nepočítá, ale určuje, zda je daná buňka obsazená, nebo volná. Volné buňky tento příznak mají nastavený na nulu. Dále se struktury buněk liší v závislosti na jejich typu.

Žádná buňka nemůže přesáhnout hranici datového bloku.

Každá buňka obsahuje informace jednoho druhu; například uchovává název a atributy klíče, seznam jeho podklíčů či název a typ některé z jeho hodnot. Každý druh dat znamená odlišný interní formát buňky.

Některé z typů buněk lze dobře rozpoznat na základě dvoubajtové signatury, která se nachází ihned za velikostí buňky. Přesně jej lze určit však pouze na základě znalosti kontextu. Například buňka reprezentující seznam podklíčů určitého klíče bude obsahovat pouze offsety na další buňky s informacemi o jménu a dalších vlastnostech klíčů. Signatury mají svůj význam při rozpoznávání konkrétního formátu zakódování určité informace. Například seznam podklíčů může být zapsán buňkami čtyř různých typů, které se z hlediska syntaxe v jednom případě liší právě pouze svojí signaturou.

Seznam signatur používaných pro některé typy buněk ukazuje tabulka 8. Existují však i buňky, jež žádnou signaturu neobsahují.