MATURITNÍ PRÁCE dokumentace

MATURITNÍ PRÁCE dokumentace

Čtení informací o PC Jakub Kubień

školní rok: 2009/2013

obor: třída:

Elektronické počítačové systémy PS4.B

Tímto děkuji panu Ing. Lukáši Haplovi za osvětlení problematiky a počáteční vedení. Mé poděkování patří Ing. Zdeňku Biolkovi,Ph.D. za odvahu vzít celou práci pod svá ochranná křídla jako druhý konzultant a také za jeho připomínky k vývoji. Dále děkuji Bc. Martinu Kovářovi za cenné rady a postřehy k programovému řešení, stejně tak Pavlu Riedlovi, který na sebe vzal nelehký úkol oponenta a poskytl důležité rady ohledně praktické stránky vývoje.

ABSTRAKT Práce se zabývá programem pro čtení konfigurace PC a vývojem jeho jednotlivých částí. Aplikace využívá data čtená ze struktur SM Biosu a díky přístupu k obvodu Super I/O je také schopna číst některé provozní vlastnosti systému. Zdrojový kód je psán v C++ za pomoci různých IDE. Při práci bylo použito technologií jako DCOM, WQL, WMI, WDF a dalších. Během vývoje byl také vytvořen ovladač pro přístup k fyzické paměti s možností jak čtení, tak zápisu. Ačkoliv jej výsledná aplikace nepoužívá, najde uplatnění v budoucích projektech, například při zkoumání systému na té nejnižší úrovni.

OBSAH ÚVOD .................................................................................................................................... 7 1

CÍLE PRÁCE ............................................................................................................. 8

2

VÝBĚR TECHNOLOGIÍ PRO ŘEŠENÍ ................................................................ 9

NÁSTROJE............................................................................................................... 9 MS Visual C++ 2010 Express ............................................................................... 9 Code::Blocks + MinGW ........................................................................................ 9 Embarcadero C++ Builder XE2 ............................................................................. 9 Windows Driver Kit 7.1.0...................................................................................... 9 Oracle VM Virtual Box ......................................................................................... 9 Windows debugger .............................................................................................. 10 WMI Delphi Code Generator............................................................................... 10 Notepad ++ .......................................................................................................... 10 Dropbox, SugraSync ............................................................................................ 10 2.2 TECHNOLOGIE: ..................................................................................................... 10 WDF (KMDF) ..................................................................................................... 10 WMI ..................................................................................................................... 11 COM .................................................................................................................... 11 WQL .................................................................................................................... 11 SM BIOS .............................................................................................................. 11 3 ZPŮSOBY ŘEŠENÍ A POUŽITÉ POSTUPY ....................................................... 12 2.1

3.1

PŘEDMLUVA ......................................................................................................... 12

ANALÝZA PROBLÉMU ........................................................................................... 12 Loader .................................................................................................................. 12 "Physmem" od Marka Russinoviche.................................................................... 12 Softwarový ovladač běžící v Kernel-módu .......................................................... 13 3.3 IMPLEMENTACE .................................................................................................... 13 3.3.1 Příprava na implementaci ............................................................................. 13 3.3.2 "Hello World" Driver ................................................................................... 14 3.3.1 "Full" RMD driver........................................................................................ 15 3.3.2 Loader........................................................................................................... 16 4 ZHODNOCENÍ DOSAŽENÝCH VÝSLEDKŮ .................................................... 19 3.2

5

PŘÍRUČKA PROGRAMÁTORA .......................................................................... 20 5.1

PŘIDÁNÍ API DO PROJEKTU................................................................................... 20

5.2 JEDNODUCHÝ PŘÍKLAD POUŽITÍ ............................................................................ 22 5.2.1 Praktická ukázka .......................................................................................... 22 6 PŘÍRUČKA UŽIVATELE ...................................................................................... 24 Poznámky:............................................................................................................ 24

7

6.1

PŘÍPRAVA KE SPUŠTĚNÍ ........................................................................................ 24

6.2

ČTENÍ Z PAMĚTI .................................................................................................... 24

6.3

ZÁPIS DO PAMĚTI .................................................................................................. 27

SHRNUTÍ .................................................................................................................. 29

7.2

PŘIPOMÍNKY K WMI ............................................................................................ 29 Seznam problémů: ............................................................................................... 30 PŘIPOMÍNKY K RMD.SYS ...................................................................................... 30

7.3

ZHODNOCENÍ ........................................................................................................ 31

7.1

SEZNAM POUŽITÝCH INFORMAČNÍCH ZDROJŮ ................................................ 32 SEZNAM POUŽITÝCH SYMBOLŮ A ZKRATEK ..................................................... 33 SEZNAM OBRÁZKŮ ....................................................................................................... 34

Střední škola informatiky, elektrotechniky a řemesel Rožnov pod Radhoštěm

7

ÚVOD Tato práce se zabývá vytvořením programu pro zjištění aktuální konfigurace PC a některých jeho provozních vlastností.

Práce byla rozdělena na dvě části. Každá z nich se týkala jiné problematiky a teprve jejich následným spojením vznikl ucelený produkt. První část se zabývá získáváním dat o testovaném PC z SM BIOSU, tu zpracoval Jakub Kubień. Část druhá má přehledně prezentovat data uživateli v podobě GUI (Graphic User Interface) a zjišťovat provozní parametry jako napětí na CPU, teplotu HDD atd. Její tvorbou se zabýval Jakub Plesník.

V této dokumentaci najdete popis řešení první části práce a její následnou implementaci do formy uceleného produktu.


1 CÍLE PRÁCE -

vytvoření programu v C++ pro zjištění konfigurace PC

-

vytvoření programu v C++ pro zjištění stavu PC (teplota CPU, stav ventilátorů apod.)

-

vytvoření dokumentace k řešené problematice

8


9

2 VÝBĚR TECHNOLOGIÍ PRO ŘEŠENÍ 2.1

Nástroje

MS Visual C++ 2010 Express C++ IDE od společnosti Microsoft. Kvůli práci s programy, které byly psány přímo pro MSVC++ kompilátor, bylo potřeba využít toto IDE. Code::Blocks + MinGW Jedná se o open-source, multiplatformní C++ IDE s kvalitním editorem a podporou mnoha kompilátorů. Pro jeho jednoduchost a povedený editor si jej zvolil autor první části práce k vývoji ovladačů, jejich API a ukázkových pracovních nástrojů pro něj. Embarcadero C++ Builder XE2 C++ IDE pro RAD primárně na platformě Windows. Díky nativní podpoře Windows API bylo zvoleno jako hlavní nástroj pro vývoj GUI celé aplikace a proběhl transfer vývoje z MS Visual C++. Windows Driver Kit 7.1.0 Soubor nástrojů, kompilátorů a ukázek zdrojových kódů pro vývoj ovladačů na platformě Windows. Byla použita verze 7 kvůli nejširšímu záběru aktuálně používaných verzí Windows, které podporuje (XP - 7). Oracle VM Virtual Box Open-source program pro virtualizaci celých PC. Velice silný nástroj se širokým spektrem využití. Sloužil jako náhrada za druhý fyzický stroj pro ladění ovladače.


10

Windows debugger Jak název napovídá, jedná se o debugger přímo od společnosti Microsoft a je jedním z nástrojů, které se používají při vývoji samotných Windows. Je velice obsáhlý, robustní a s tím se pojí jistá těžkopádnost, ale svou práci zastane na výbornou. Zde byl použit při vývoji ovladačů. WMI Delphi Code Generator Vynikající utilita, která v přehledném GUI generuje zdrojový kód pro přístup k informacím ve WMI skrze COM. Podporuje širokou škálu programovacích jazyků používaných na platformě Windows včetně jejich úprav pro různé kompilátory (MS C++, Borland/Embarcadero C++, C#, Delphi/Object Pascal, Free Pascal). Notepad ++ Open-source textový editor čistě pro Windows. Přehledný, praktický, s dostatkem funkcí. Díky možnosti zvýraznění syntaxe byl použit pro rychlou editaci

kódu

a

prohlížení materiálů. Dropbox, SugraSync Pomocné programy pro cloudová uložiště. Kvůli nutnosti sdílení zdrojových kódů bylo jejich využití nejlepší cestou.

2.2

Technologie:

WDF (KMDF) WDF neboli Windows Driver Foundation je nový model implementace systémových

ovladačů v systémech Windows NT a vyšších. Oproti svému předchůdci

WDM (Windows Driver Model) zlehčuje vývoj tím, že dovoluje rychle vytvořit základní funkční kostru ovladače a sám se postará o ošetření většiny systémových událostí. Dělí se na dvě části. UMDF pro ovladače běžící v "user-mode" a KMDF pro ovladače v režimu jádra. Zde bylo použito KMDF (Kernel Mode Driver Fra-


11

mework), protože je to jediná cesta, kterou se můžeme dostat ze systému k fyzické paměti. WMI Windows Management Instrumentation je jedna z mnoha služeb systému Windows (implementována od Windows 2000), která má za úkol usnadnit práci hlavně administrátorům a správcům sítí s větším množstvím počítačů. Umožňuje je nastavovat, číst jejich konfiguraci, a to jak lokálně, tak vzdáleně přes síť. COM Commponent Object Model je název standardu firmy Microsoft, který nezávisle na programovacím jazyku (musí být objektově orientovaný) definuje objekty, jež mohou mezi sebou komunikovat a volat své metody. Používá se pro komunikaci mezi procesy v rámci systému i sítě (Distributed COM). Zde se díky němu přistupovalo k strukturám WMI. WQL WQL je zkratka pro WMI Query Language. Jedná se o odnož ANSI SQL a slouží k procházení struktur WMI. SM BIOS Specifikace System Management BIOS vydaná a spravovaná DMTF je standardem pro výrobce SW a HW pro platformu PC. Definuje, jaké informace o sobě mají poskytovat jednotlivé komponenty. Stanovuje také formát struktur pro jejich uložení.


12

3 ZPŮSOBY ŘEŠENÍ A POUŽITÉ POSTUPY Předmluva

3.1

Pro pochopení směru vývoje projektu je potřeba nastínit obsah rozhovoru realizačního týmu s původním vedoucím práce Ing. Lukášem Haplem. V konzultacích, které začaly již na konci školního roku 2011/2012, pan Hapl vyslovil přání, aby pro načítání SM BIOS dat nebyly použity standardní nástroje a postupy, ale hledaly se jiné, alternativní cesty. Sám navrhl řešení v podobě programu "PHYSMEM".

Analýza problému

3.2

Informace o konfiguraci počítače jsou uloženy ve strukturách SM BIOSu. Windows je načte během startu a prezentuje je pomocí svých služeb a technologií. Autor se k nim ovšem pokusil dostat přímo. Stěžejním problémem bylo čtení z fyzické paměti a následné nalezení struktur SM BIOSu. Další na řadě byl parsing jednotlivých struktur a uložení výsledků. Zvažovaly se následující metody: Loader provedený jako 16bitový program psaný v Turbo Pascalu. Ten má díky emulaci DOSu přístup do fyzické paměti (první MB) jako BIOS. Přečtená data by exportoval ve formě *.bin souboru, který by poté musela parsovat samotná GUI aplikace. Nehledě na těžkopádnost řešení (problémy se spouštěním 16bitových aplikací pomocí Win. API) je tu také omezení v podobě funkčnosti pouze na 32bitovém systému. "Physmem" od Marka Russinoviche je program psaný v C++ primárně pro Windows XP. Ke čtení fyzické paměti používá nezdokumentovanou funkci Windows API, kterou si namapuje přímo ze systémového NT.DLL. Jeho kód by se mohl implementovat přímo do GUI aplikace, ale je použitelný pouze pod 32bitovými systémy (odzkoušeno jen na Windows XP).


13

Softwarový ovladač běžící v Kernel-módu Ovladač pro systém Windows, jež provede čtení z fyzické paměti. Zřejmou nevýhodou je náročnost realizace tohoto řešení. Vývoj STABILNÍHO ovladače je záležitost měsíců a je potřeba zkušeného programátora kvůli úskalím, která s sebou tento vývoj nese. Plusem je naopak podpora 32bit i 64bit systémů, stejně jako všech aktuálně používaných verzí Windows. Pro malé firmy a domácí kutily má toto řešení ale háček v podobě bezpečnostní politiky Microsoftu. U 64bitových Windows je vyžadován digitální podpis. Ten se sice dá obejít, ale pro běžného uživatele a praktické nasazení výsledné aplikace je to neřešitelný problém. Autor se po důkladném zvážení rozhodl pro softwarový ovladač. Tato možnost je z důvodu případného dalšího vývoje tou nejlepší.

3.3

Implementace

Zde bude nastíněn postup řešení problému s důrazem na podstatné a zajímavé pasáže. Výstupem implementační části je ovladač Rmd.sys (Radhošť memory driver) a pak také funkce "Loader()" v samotném programu. Implementace začala čtyřměsíční teoretickou přípravou s pomocí knihy DEVELOPING DRIVERS

WITH THE

MICROSOFT WINDOWS DRIVER FOUNDATION. Během této doby

autor pochopil základy: 1) programování ovladačů 2) jejich chování a vnitřních pochodů 3) programové struktury

3.3.1

Příprava na implementaci

Před samotným začátkem vývoje bylo potřeba vytvořit a nastavit testovací prostředí. Díky faktu, že driver běží v kernel-módu, se nedají použít běžné debuggery, jelikož systém, ve kterém se ovladač testuje, není stabilní. V případě chyby kernel vyvolá tzv. BSOD a řízeně


14

shodí celý systém. Na scénu proto vstupuje tzv. remote-debugging. Jedná se o debugger, který se teprve připojuje k testovacímu systému na externím stroji. Nejjednodušším řešením je tedy zapnout druhý fyzický počítač a na něm testovat. K připojení externího debuggeru se nabízí více možností, ovšem pro Windows XP a domácí použití je nejdostupnější propojení přes sériový port. Autor se však rozhodl pro modernější přístup, a to virtualizaci testovacího stroje. V podání VM VirtualBoxu mělo toto řešení dosti podstatná omezení, ale pro počáteční vývoj jej bylo možné použít.

3.3.2

"Hello World" Driver

Základní část celého vývoje. Zde se vytvářela kompletní kostra ovladače pro jeho stabilní načtení a běh. Tato verze ovladače měla jednoduchý úkol: odpovědět na volání aplikace a vrátit zpět pozdrav. Tím se otestoval jak běh ovladače, tak funkčnost IRQ. Po každé důležité operaci byla v kódu pro zjednodušení hledání chyb použita funkce "DbgPrint()". Jejím účelem je poslat skrze systém zprávu do aktuálně připojeného/ných debuggerů.

Obr. č. 1: ukázka kódu pro ladění

První volanou funkcí v případě ovladače je "DriverEntry". Jedná se o ekvivalent funkce "main" známé z běžného programování aplikací pro user-mód. V ní si ovladač vytváří jednotlivé objekty pro svůj běh. Dále zde probíhá registrace funkcí k jednotlivým frameworkovým voláním. Je také vytvořen symbolický link pro jednodušší volání ovladače a nastavena metoda IO operací (zde "Buffered_IO").

Obr. č. 2: kód nastavující metodu IO


15

Pro vykonání IRQ a návrat pozdravu byla vytvořena funkce "Rmd_read" přiřazená k události "IRP_MJ_READ". Ta navazuje na volání z Win API funkcí "ReadFile()". Technicky probíhá návrat hodnoty pomocí kopírování předem připraveného bufferu s textem do bufferu IRP, který bude poslán zpět do user-módu. 3.3.1

"Full" RMD driver

Další krok ve vývoji. Cílem bylo naprogramování samotného čtení z paměti (k němu se přidal také zápis) a Rmd_API pro zjednodušení nasazení ovladače v aplikacích. Vývoj probíhal souběžně a pro potřeby testování API vznikla také konzolová aplikace RmdTestUtil. Její zdrojový kód lze použít jako základ pro práci a vývoj s Rmd_API. Oproti předchozí verzi se zde udála zásadní změna v komunikaci s user-módem. Funkce "ReadFile()" potažmo "WriteFile()" byla nahrazena funkcí "DeviceIoControl()". Díky ní je komunikace lehce škálovatelná. Používají se totiž tzv. IoCtlCode`s, což jsou specifické kódy pro každou funkci, kterou voláme. Kódy definuje uživatel pomocí makra "#define IOCTL_Device_Function CTL_CODE()" a nesmí být nižší než 0x800, aby nekolidovaly se systémovými voláními.

Obr. č. 3: kód definující funkci a její IoCtCode

Aby byl ovladač schopný toto zpracovat, prochází každé volání přes vnitřní case/switch logiku, jež právě pomocí IoCtlCode volá vnitřní funkce a také filtruje nespecifikovaná volání


16

Obr. č. 4: case/switch logika volající funkce na základě IoCtlCode´s

Na otestování funkčnosti čtení z paměti byl použit program PHYSMEM jako důvěryhodný zdroj dat pro porovnání s výstupem ovladače. Ovladač byl dokončen podle plánu, dokonce byla přidána funkce pro zápis do fyzické paměti. Dále je také nachystána kostra pro realizaci funkcí na přímý přístup k portům.

3.3.2

Loader

Celý ovladač je pouze nástroj a jeho funkce jsou co nejvíce univerzální, aby mohl být použit i u jiných projektů. Samotné vyhledání dat potřebných k zjištění identifikace má proto na starost až funkce "Loader()", která je součástí GUI aplikace. Její úkoly jsou následující:


17

1) najít první strukturu SM Biosu 2) načíst všechna data 3) provést parsing informací 4) poskytnout data k zobrazení Bohužel ani po vynaložení značného úsilí nebyl autor schopen najít řetězec _SM_, jímž začíná první struktura SM Biosu. Za vzniklý problém může operační systém, který celý 1. MB paměti včetně SM Biosu přesune neznámo kam. Sám si předtím načte data do svých struktur. Autorovi se sice náhodou během testování ovladače povedlo na počáteční strukturu narazit, ale ihned po restartu již na dané adrese nic nebylo.

Obr. č. 5: náhodný nález počáteční struktury SM Biosu

Proto bylo potřeba se uchýlit k náhradnímu řešení, tzv. "plánu B". Ten spočívá v načtení již interpretovaných hodnot přímo ze systému. K tomu slouží služba WMI (Windows Management Instrumentation). Ačkoliv toto řešení není zcela dostačující, stále může poskytnout zajímavé informace. Další alternativy, které WMI nabízí, jsou nastíněny ve zhodnocení práce. WMI se z pohledu programátora chová jako DCOM (Distributed Object Component Model) služba, je tedy velice jednoduché dostat se k ní z velkého množství programovacích a


18

skriptovacích jazyků. Zde bylo použito právě komunikace pomocí COM. Protože GUI aplikace už má vytvořenou instanci COM od spuštění, stačilo se pouze připojit k WMI a začít načítat data. Samotné WMI funguje jako databáze, a proto se k datům přistupuje přes WQL podobně jako pomocí SQL k jiným databázím.

Obr. č. 6: kód pro načtení názvu Biosu z WMI

Funkce "Loader()" je volána hned po inicializaci aplikace a načítá data do globálních instancí předem připravených tříd. Odtud si je potom vyzvedává GUI pro zobrazení v závislosti na chování uživatele.


19

4 ZHODNOCENÍ DOSAŽENÝCH VÝSLEDKŮ V práci bylo úspěšně dosaženo těchto cílů:  Vytvoření programu v C++ pro zjištění konfigurace PC Podařilo se nalézt a implementovat funkční cestu vedoucí k načtení konfiguračních dat. Dále byla vytvořena aplikace pro jejich vizuální prezentaci.  Vytvoření programu v C++ pro zjištění stavu PC (teplota CPU, stav ventilátorů apod.) Ačkoliv uvedený bod nepatřil k náplni této části práce, po konzultaci s kolegou mohu potvrdit jeho splnění. Výstupem je kromě aktuálních hodnot také graf a historie měření.  Vytvoření dokumentace k řešené problematice Byla vytvořena dokumentace, kterou právě čtete. Její součástí je stručný úvod do problematiky celého vývoje a chronologický popis jeho průběhu.


5 PŘÍRUČKA PROGRAMÁTORA 5.1

Přidání API do projektu

1) Zkopírujte Rmd_API.h do include složky svého kompileru (zde MingW)

Obr. č. 7: kopírování Rmd_API.h

20


21

2) Zkopírujte Rmd_API.cpp k souborům, ze kterých bude voláno

Obr. č. 8: kopírování Rmd_API.cpp

3) Do souboru, z něhož budou volány funkce API, přidejte direktivu #include

Obr. č. 9: ukázka direktivy #include


22

Nyní máte hotovou konfiguraci API a můžete jej začít používat.

Jednoduchý příklad použití

5.2

Použití Rmd_API je velmi jednoduché a intuitivní. Nejdříve si však ukážeme funkce, které máme k dispozici.

Tabulka č. 1: seznam funkcí

5.2.1

Název funkce

Stručný popis

rmdMemRead()

Čtení z fyzické paměti

rmdMemWrite()

Zápis do fyzické paměti

rmdOpenDriver()

Inicializace ovladače

rmdCloseDriver()

Smazání ukazatele na ovladač

Praktická ukázka

Toto je zdrojový kód, na kterém si prakticky ukážeme postup práce s Rmd_API . Jedná se o ukázku konzolové aplikace, jež na adresu vloženou uživatelem uloží řetězec "Ahoj".


23

Obr. č. 10: ukázka jednoduchého programu pro zápis do fyz. paměti

1. zavoláme "rmdOpenDriver()" 2. napíšeme část kódu, kde voláme libovolný počet funkcí Rmd_API 3. po skončení práce s ovladačem nesmíme zapomenout zavolat "rmdCloseDriver()"


24

6 PŘÍRUČKA UŽIVATELE Příručka pro použití programu RmdTestUtil.exe, který je součástí práce. Program slouží k otestování a demonstraci funkcí ovladače. Poznámky:  Ovladač je v alfa verzi a není zcela stabilní. Doporučuje se spouštět ho na virtuálním počítači!  Prozatím je podporován pouze systém MS Windows XP.

6.1

Příprava ke spuštění

1. otevřete složku X: \odevzdání\bin 2. zkopírujte složku Rmd na svůj virtuální počítač

6.2

Čtení z paměti

1. otevřete složku Rmd na vašem virtuálním stroji 2. spusťte RunME.bat

Obr. č. 11: soubory pro test ovladače


25

3. objeví se jednoduché menu s třemi volbami, vybereme volbu jedna (čtení z paměti)

Obr. č. 12: ukázka volby pro čtení z paměti

4. program nás vybídne k vložení fyzické adresy, ze které se bude číst v hexadecimálním formátu

Obr. č. 13: ukázka zadání fyz. adresy pro čtení


26

5. po přečtení dat z paměti (je zadána pevná velikost bloku pro čtení 512 bajtů) je program vypíše ve formě sloupců hexadecimálních čísel po jednom bajtu a také jako blok ASCII znaků na pravé straně

Obr. č. 14: ukázka výpisu dat přečtených z paměti

6. pro ukončení programu vložíme číslo 9 a stiskneme Enter


6.3

27

Zápis do paměti

Zápis do paměti probíhá podobně, s tím rozdílem, že jej vybereme jako možnost v menu a na vloženou adresu se vpisuje předem nastavená konstanta "Ahoj". To je pro testovací účely zcela dostačující. POZOR !!! Před zápisem na jakékoliv místo v paměti si jej nejprve zobrazte. Pokud jsou tam jakákoliv data, nezapisujte! Hrozí zhroucení systému.

Obr. č. 15: zobrazení zapsaných dat ve dvou nezávislých programech


Obr. č. 16: ukázka volby a zadání adresy pro zápis do fyz. paměti

28


29

7 SHRNUTÍ

Celý program RAT (Rožnov Analysis Tool) je stále ve fázi vývoje, a proto by si prezentovaná verze zasloužila přídomek ALFA. Ačkoliv se projekt může zdát plný funkcionalit, ani zdaleka nedosáhl na své kvalitativní maximum. WMI jako takové nabízí mnohem více možností a je schopno poskytnout detailnější informace, než jaké jsou zde prezentovány. Proto je vhodnější brát momentální verzi programu spíše jako ukázku. Ovladač čeká také ještě spousta práce. Například RAT momentálně využívá pro přístup k portům (a následně Super IO) ovladač PortTalk. Ten by měl být do budoucna nahrazen právě Rmd. Dále je ovladač naprosto neošetřený vůči chybám a jeho provoz se v nynější verzi doporučuje pouze na vlastní nebezpečí. Následující kapitoly obsahují vždy podrobný popis nejpalčivějších problémů.

7.1

Připomínky k WMI

Hodnoty, které aplikace načítá z WMI, jsou již vyparsovány systémem, což je z jedné strany značné ulehčení práce pro programátora, ale také to s sebou nese jistá úskalí. Z neznámého důvodu je spousta struktur poskytovaných systémem poloprázdných, přitom programy jako Everest či AIDA chybějící informace nabízejí. Po delším bádání přišel autor na řešení tohoto problému, a to pomocí třídy MSSMBios_RawSMBiosTables poskytované samotným WMI. Tato třída je blok surových dat, který v sobě zahrnuje všechny struktury SM Biosu. Ironií je, že vyparsováním těchto dat dostaneme daleko více informací, než kolik nám jich servíruje WMI. Dalším problémem, patrným na první pohled, je omezení informací například o pamětech, nebo pevných discích vždy na jedno zařízení (paměťový modul). To je způsobeno tím, že data načtená z WMI jsou ukládána do tříd rozdělených podle zařízení a každá třída má jednu globální instanci. Pokud WMI poskytne informace o více zařízeních, tak funkce "Loader()" uloží pouze informace o tom posledním (v případě pevných disků prvním) z nich. Řešením je vytvořit pole globálních instancí tříd resp. pole ukazatelů na tyto instance. Bohužel autorovi se toto nepovedlo včas zprovoznit.


30

Seznam problémů: 1. parser surových SM BIOS dat 2. pole více globálních instancí jedné třídy 3. splash screen při startu aplikace 4. export dat do xml, nebo txt souboru

7.2

Připomínky k Rmd.sys

Autor by rád postupem času poskytl hotový ovladač včetně API volně ke stažení pro každého, kdo má zájem se ponořit do tajů systému na té nejnižší úrovni. K dosažení tohoto cíle však vede ještě dlouhá cesta. V Rmd_API chybí například funkce pro dynamické nahrání a spuštění ovladače, proto byl autor nucen použít externí nástroj. Celá tato funkcionalita musí být před dokončením vývoje ovladače převedena do Rmd_API. Další na řadě je vývoj funkcí pro přímý přístup k portům (čtení / zápis). Autor si již vyhledal a nastudoval potřebné materiály i zdroje potřebné k realizaci vývoje, ovšem na vývoj samotný mu už nezbyl čas. Teprve po implementování těchto funkcí bude ovladač považován za dokončený. Důležitým úkolem, který je třeba vyřešit, je také ošetření vstupů a vnitřních chyb ovladače. Jmenovitě třeba: 1. kontrola velikosti adresy (pro 32 i 64 bit) 2. reakce na zamítnutí alokace paměti 3. kontrola zda se nechystáme číst mimo rozsah paměti (zadaná adresa + místo alokované pro čtení sahají mimo exitující paměť)


31

Nejvyšší metou v tomto ohledu by bylo splnění požadavků pro WHQL certifikaci poskytovanou samotnou firmou Microsoft. Její získání je ovšem z hlediska momentálního domácího vývoje zcela nereálné.

7.3

Zhodnocení

Jako největší problém se nakonec ukázal čas, a to zejména kvůli práci na nakonec nevyužitém ovladači. Jeho složitý vývoj a hlavně neúspěšné pokusy o nalezení struktur SM Biosu si vyžádaly mnoho času na úkor odladění práce s WMI. Největším přínosem pro autora byla, kromě osvěžení si znalosti C++, jednoznačně možnost seznámit se s vývojem ovladačů pro kernel-mód pod systémem Windows. Jedná se o dosti odlišné prostředí s úplně jinými nároky jak na kód, tak na programátora. Proto se z tohoto vývoje stala neocenitelná zkušenost, která se může hodit v budoucím zaměstnání. Ani poznatky získané při práci s WMI nejsou k zahození, protože se jedná o technologii běžně využívanou v praxi. Sousta skriptů a aplikací využívaných systémovými administrátory je svázána právě s WMI a funkcemi, jež nabízí. Další dobrou zkušeností, kterou by chtěl autor více prohloubit, je základní znalost COM a jeho využití například v meziprocesové komunikaci.


32

SEZNAM POUŽITÝCH INFORMAČNÍCH ZDROJŮ -

FALK, Brandon. Unlocked Physical Memory. Brandon Falk [online]. 2007 [cit. 2013-02-27]. Dostupné z: http://www.brandonfa.lk/ulpm/index.html

-

SMBIOS Peek. Code Project [online]. 2008 [cit. 2013-02-27]. Dostupné z: http://www.codeproject.com/Articles/24730/SMBIOS-Peek

-

ORWICK, Penny a Guy SMITH. Developing Drivers with the Microsoft Windows Driver Foundation. One Microsoft Way Redmond, Washington 98052-6399: Microsoft Press, 2007. ISBN 9780735623743.


SEZNAM POUŽITÝCH SYMBOLŮ A ZKRATEK BIOS

Basic Input Output System

SM BIOS

Self Managed BIOS

SQL

Structured Query Language

DMTF

Distributed Management Task Force

IRQ

Input/output Request

IRP

Input/output Request Packet

API

Aplication Interface

WHQL

Windows Hardware Quality Labs

IDE

Integrated Development Environment

RAD

Rapid Application Development

GUI

Graphic User Interface

MinGW

Minimalist GNU for Windows

33


34

SEZNAM OBRÁZKŮ Obr. č. 1: Ukázka kódu pro ladění ...................................................................................... 14 Obr. č. 2: kód nastavující metodu IO .................................................................................. 14 Obr. č. 3: kód definující funkci a její IoCtCode ................................................................. 15 Obr. č. 4: case/switch logika volající funkce na základě IoCtlCode´s ................................ 16 Obr. č. 5: náhodný nález počáteční struktury SM Biosu..................................................... 17 Obr. č. 6: kód pro načtení názvu Biosu z WMI .................................................................. 18 Obr. č. 7: kopírování Rmd_API.h ....................................................................................... 20 Obr. č. 8: kopírování Rmd_API.cpp ................................................................................... 21 Obr. č. 9: ukázka direktivy #include ................................................................................... 21 Obr. č. 10: ukázka jednoduchého programu pro zápis do fyz. paměti ................................ 23 Obr. č. 11: soubory pro test ovladače.................................................................................. 24 Obr. č. 12: ukázka volby pro čtení z paměti ....................................................................... 25 Obr. č. 13: ukázka zadání fyz. adresy pro čtení .................................................................. 25 Obr. č. 14: ukázka výpisu dat přečtených z paměti............................................................. 26 Obr. č. 15: zobrazení zapsaných dat ve dvou nezávislých programech .............................. 27 Obr. č. 16: ukázka volby a zadání adresy pro zápis do fyz. paměti .................................... 28

MATURITNÍ PRÁCE dokumentace

Recommend Documents