Ladiaci program je druhá vec po kompilátore na vytváranie programov. Mnohí z tých, ktorí píšu počítačové programy a používajú debugger, si však neuvedomujú princípy a mechanizmy jeho práce.
Je ťažké byť debuggerom...
Vzhľadom na skutočnosť, že programátori používajú debugger vo dne v noci, najmä keď vstúpia do režimu hlbokého ladenia, stojí za to povedať, že ak by debugger nebol program, ale kus hardvéru, pravdepodobne by sa prehrial a pokazil. Pretože ani kompilátor nemá toľko práce, koľko dostane debugger.
Samozrejme, keďže teraz existuje veľa rôznych programovacích jazykov, debuggery pre každý z nich sú odlišné. A samozrejme, pre rôzne kategórie týchto jazykov existujú rozdiely v práci debuggerov: napríklad debugger pre interpretované programy Ruby bude fungovať inak ako pre Javu kompilovanú do bajtového kódu a debugger pre Javu zasa, bude mať rozdiely od debuggera Visual C ++.
Budem hovoriť o ladení pre platformu Windows. Po pochopení princípov práce debuggerov pre to bude možné porozumieť ladiacim programom pre systémy POSIX a ladiacim programom, ktoré nepracujú na úrovni operačného systému, ale na úrovni virtuálneho stroja alebo nejakého tlmočníka.
Debuggery pre Windows: Dva druhy
Existujú dva zásadne odlišné druhy ladiacich programov pre Windows. Myslím, že každý ako prvý narazil, keď programoval v Delphi (neprogramoval v ňom? Ťažko uveriť. Čo si programoval v škole a v juniorke?). Toto sú vlastné ladiace programy. Je ich veľa a existujú samostatne a (mimochodom najmä často) ako súčasť integrovaných prostredí vývoja aplikácií. OllyDbg sa tradične rozlišuje medzi debuggermi distribuovanými ako samostatné softvérové produkty a kedysi som o tom písal v „Computer News“.
Druhým typom debuggera je ladiaci program jadra operačného systému. Nachádzajú sa a používajú menej často a výrazne sa líšia svojim dizajnom od debuggerov pre vlastné aplikácie. Najznámejším a zároveň najlepším z kernel debuggerov je SoftIce. Možno ste o ňom nielen počuli, ale dokonca ho aj používali.
Keďže práca každého z dvoch typov debuggerov má svoje špecifiká, o každom z nich vám poviem viac.
Debugger vlastných aplikácií
Ladiaci nástroj vlastných aplikácií je jednoduchší, keďže tú najšpinavšiu a najšpinavšiu prácu preberá operačný systém. Windows má špeciálne programovacie rozhrania na ladenie aplikácií na úrovni používateľov - nazývajú sa Windows Debugging API. Sú to ladiace API, ktoré používajú všetky debuggery zabudované do obľúbených Windows IDE.
Na spustenie ladenia musí debugger spustiť ladený proces špeciálnym spôsobom, aby systém vedel, že tento proces bude prebiehať ladením. Potom sa začne ladiaci cyklus: program sa spustí, kým nenastane určitá udalosť, ktorá sa nazýva ladiaca udalosť alebo ladiaca udalosť. Toto spustí slučku ladenia v samostatnom vlákne, aby sa zabránilo zaveseniu ladiaceho nástroja.
Ale toto je len začiatok. Pretože to najzaujímavejšie v práci debuggera začína už vtedy, keď nastala udalosť ladenia. Koniec koncov, čo je vlastne úlohou debuggera? Pomôcť programátorovi lokalizovať chybu na konkrétnu funkciu, konkrétnu operáciu alebo špecifickú premennú. V tejto náročnej úlohe môže debuggerovi pomôcť aj operačný systém.
Došlo teda k udalosti ladenia a potom musíme nejako zistiť, ako to súvisí s textom programu. To je možné iba vtedy, ak samotný program obsahuje špeciálne informácie o ladení - tabuľku symbolov ladenia. Obsahuje informácie o zhode medzi adresami a názvami funkcií, typmi údajov, číslami kódových riadkov. Práve vďaka nim je možné ladenie, ktoré pozná každý programátor Windows. Tabuľky symbolov majú rôzne formáty, a preto nie je vždy možné ladiť program zostavený kompilátorom jedného dodávateľa pomocou debuggera od iného dodávateľa. Najbežnejší formát je však stále možné špecifikovať - jedná sa o PDB (programová databáza) a bol vyvinutý, samozrejme, spoločnosťou Microsoft.
Ak je teda tabuľka symbolov ladenia vo formáte PDB, potom môžete použiť špeciálny nástroj od spoločnosti Microsoft - symbolický ladiaci procesor. Kedysi bola súčasťou jadra systému a volala sa Imagehlp.dll, ale už dávno bola oddelená do samostatnej knižnice. Znakový procesor vám umožňuje nájsť najbližšiu otvorenú funkciu alebo globálnu premennú na danej adrese, ako aj číslo riadku a názov zdrojového súboru, v ktorom sa tento riadok nachádza. Podporované sú aj inverzné operácie, napríklad hľadanie adresy funkcie podľa jej názvu.
Toto, samozrejme, nie je všetka práca, ktorú vykonáva ladiaci program vlastných aplikácií. Napríklad pri ladení viacvláknových aplikácií existuje veľa veľmi jemných problémov súvisiacich s interakciou vlákien. Dokonca aj pri ladení relatívne jednoduchých vecí, ako sú služby, existujú nuansy.
Ale teraz sa nebudeme zaoberať nuansami - na konci článku vám poviem, kde si o nich môžete prečítať. Teraz sa pozrime na ladiče jadra.
Debugger jadra
Debuggery jadra sú oveľa zložitejšie programy ako debuggery vlastných aplikácií a hádam je pochopiteľné prečo: nemajú pomocníka operačného systému. V tomto prípade je ich klientkou, pretože je to ona, ktorú musia v konečnom dôsledku odladiť.
Väčšina ladiacich programov jadra vyžaduje na spustenie dva počítače spojené káblom nulového modemu. Nulový modem je spôsob, ako pripojiť dva počítače priamo pomocou kábla cez ich porty COM alebo LTP. Druhý počítač je potrebný, pretože časť debuggera sediaca na prvom (tá, kde je nainštalovaný ladený systém) má obmedzený prístup k hardvéru, a preto všetky výstupy dát idú cez nulový modem do druhého počítača.
V moderných procesoroch architektúry Intel x86 sú špeciálne registre ladenia (v starom 368 aj v novších modeloch procesorov je ich len osem, označujú sa ako DR0-DR7). Tieto registre umožňujú ladiacemu programu nastaviť kontrolné body na čítanie a zápis pamäte, ako aj na I/O porty. Vo všeobecnosti všetko vyzerá presne takto a nemyslím si, že teraz stojí za to podrobne popisovať, za čo je zodpovedný každý z registrov ladenia, aké prerušenia sa používajú na implementáciu bodov prerušenia a poskytovanie ďalších podobných informácií. Radšej by som hovoril o konkrétnych existujúcich debuggeroch jadra pre Windows.
No, v prvom rade je to debugger zabudovaný do samotného jadra operačného systému. Je dostupný vo všetkých operačných systémoch NT počnúc Windows 2000. Je súčasťou súboru NTOSKRNL.EXE a možno ho aktivovať nastavením voľby "/ Debug" pre operačný systém v BOOT.INI. Tento debugger potrebuje pripojenie nulovým modemom a druhý počítač s rovnakým operačným systémom.
Existuje ďalší debugger jadra od spoločnosti Microsoft - WinDBG. Presne povedané, nejde o ladiaci program jadra, ale o hybridný debugger, ktorý možno použiť aj na ladenie aplikácií na úrovni používateľa. Na rozdiel od debuggeru zabudovaného v jadre má grafický shell, a preto je jeho použitie jednoduchšie. Tento debugger podporuje aj špeciálne rozšírenia, ktoré sa môžu hodiť pri niektorých úlohách ladenia. Na ladenie jadra sú však potrebné aj dva počítače.
Existuje však ladiaci program jadra, ktorý dokáže ladiť na jednom počítači. Toto je SoftIce. SoftIce zároveň dokáže ladiť aj aplikačné programy. Použitie tohto debuggeru pre užívateľské programy má opodstatnenie napríklad v prípade ladenia systémov v reálnom čase viazaných na systémový časovač. Ak ladíte obyčajným debuggerom, výsledok môže byť nesprávny, aj keď program beží správne a SoftIce zastaví program aj časovač. To je užitočné pri ladení viacvláknových aplikácií. SoftIce má navyše veľmi, veľmi dobre rozvinutý spôsob zobrazovania informácií o všetkých vláknach v systéme, o synchronizácii vlákien pre viacvláknové aplikácie, informácií o úchytke „ah ... Jedinou nevýhodou tohto debuggera je jeho komplexnosť pre programátora aplikácií. Ale z ladiacich programov jadra je to najjednoduchšie a najefektívnejšie.
Pre tých najzaujímavejších
Teraz, samozrejme, hovoriť o debuggeroch pre aplikácie Windows nie je také relevantné ako pred desiatimi rokmi. O internet sa začal zaujímať celý svet a hlavnými užívateľmi SoftIce boli crackeri, neúnavní pracovníci v oblasti pirátstva. Nie je to však také zlé. Komunikácia so SoftIce nepochybne rozvíja človeka, čo sa týka vedomostí o počítači, aj keď, samozrejme, ak komunikujete iba s debuggermi a nekomunikujete so skutočnými ľuďmi, nejaké vedľajšie účinky sú možné.. No, myslím, že o tom už každý vie.
Ladiace programy sú niektoré z najvýraznejších typov softvéru, ale z hľadiska vývoja sú aj ladiace programy na úrovni používateľa pomerne zložité. Ak však máte chuť a čas na vývoj vlastného debuggera, vaše znalosti operačných systémov a programovania sa výrazne zvýšia, čo znamená, že sa zvýšia aj šance na dobre platenú prácu.
Takže, ak si chcete vytvoriť svoj vlastný debugger, mali by ste si najprv prečítať materiály na túto tému. Podľa môjho názoru je najlepším miestom, kde začať, kniha Johna Robbinsa Debugging Windows Applications. Je už starý, vydaný v roku 2001, ale informácie v ňom obsiahnuté sú aktuálne aj teraz, keďže majú všeobecný, ba až trochu zásadný charakter. Táto kniha obsahuje príklady písania debuggerov pre Windows a je tiež užitočná, ak programujete v C ++ a chcete lepšie pochopiť spracovanie výnimiek. V skutočnosti som z tejto knihy získal informácie o debuggeroch uvedených v článku. Ak nemôžete nájsť túto knihu (nakoniec je už dosť stará), existuje niekoľko adries, ktoré sa vám môžu hodiť. Prvý je takýto: www.xakep.ru/post/19158/default.asp. Tento článok z časopisu „Hacker“ hovorí o ladiacich programoch jadra trochu viac ako ja a okrem toho obsahuje kód jednoduchého debuggera. A na kalashnikoff.ru/Assembler/issues/016.htm sa môžete naučiť, ako napísať debugger DOS. Ale, samozrejme, najlepšie je prečítať si MSDN a po ceste nájsť open source debugger, aby ste na to prišli. A samozrejme, ak sa pustíte do písania debuggera, potom úspech v tejto ťažkej úlohe!
- Autori:
Barinov S.S., Ševčenko O.G.
- Rok:
- Zdroj:
Informatika a počítačové technológie / Materiály VI. medzinárodnej vedecko-technickej konferencie študentov, doktorandov a mladých vedcov - 23.-25. novembra 2010, Doneck, DonNTU. - 2010 .-- 448 s.
anotácia
Je poskytnutá porovnávacia analýza ladenia užívateľského režimu a režimu jadra aplikovaného na operačný systém. Microsoft Windows, zdôrazňujú rozdiely a problémy organizácie ladenia posledne menovaných. Na základe získaných výsledkov sú formulované hlavné požiadavky na konštrukciu kernel-mode debuggerov v prípade núdzového a interaktívneho ladenia. Bola vykonaná analýza existujúcich riešení z hľadiska súladu s požiadavkami. Osobitná pozornosť sa venuje programu Microsoft Windows Debugger.
Hlavná časť
Ladenie je proces identifikácie a opravy príčin chýb v softvér... V niektorých projektoch zaberá ladenie až 50 % celkového času vývoja. Ladenie je možné výrazne zjednodušiť použitím špecializovaných nástrojov, ktoré sa neustále zdokonaľujú. Hlavným takýmto nástrojom je debugger, ktorý vám umožňuje kontrolovať vykonávanie softvéru, sledovať jeho priebeh a zasahovať do neho. Nástroje na ladenie jadra používajú predovšetkým vývojári ovládačov.
Sada nástrojov na vývoj aplikačného softvéru ponúka programátorovi široké možnosti. Akékoľvek integrované vývojové prostredie tiež zahŕňa možnosť ladenia bez potreby nástrojov tretích strán. Ak sa bavíme najmä o systémovom softvéri a vývoji ovládačov, tak vzhľadom na jeho špecifiká je proces vývoja mimoriadne náročný a málo automatizovaný. Všetky fázy vývoja vrátane ladenia sú oddelené. Na vykonanie každého z nich sú potrebné špeciálne podmienky: písanie programového kódu sa vykonáva na plnohodnotnom počítačový systém, ladenie - na ladiacom systéme, testovanie - podľa okolností atď. Samotný ladiaci program v režime jadra sa ťažšie učí a je preto menej užívateľsky príjemný.
Vo všeobecnosti môžeme hovoriť o nedostatku nástrojov na ladenie jadra. Aj keď sú takéto nástroje k dispozícii, často nie je potrebné hovoriť o alternatívach. Napríklad ladiaci program Microsoft Windows má príliš vysoký vstupný prah. Mnoho programátorov pri stretnutí s ním hovorí o prvej negatívnej skúsenosti a väčšina jeho schopností zostáva nevyžiadaná.
Na základe štruktúry virtuálneho adresného priestoru, ak dôjde k chybe v aplikácii, v dôsledku ktorej aplikácia zapíše údaje na ľubovoľné miesto v pamäti, potom aplikácia poškodí iba vlastnú pamäť a neovplyvní operáciu iných aplikácií a operačného systému. Zatiaľ čo kód v režime jadra je schopný poškodiť dôležité dátové štruktúry operačného systému, čo nevyhnutne povedie k všeobecnému zlyhaniu. Neefektívne napísaný ovládač môže tiež spôsobiť vážne poškodenie celého operačného systému.
- Moderné debuggery poskytujú nasledovné základné funkcie:
- ladenie úrovne zdrojový kód;
- kontrola vykonávania;
- prezeranie a zmena pamäte;
- prezeranie a zmena obsahu registrov procesora;
- zobraziť zásobník hovorov.
Pre uľahčenie práce s rozobratým kódom, tzv. symboly ladenia. Počas spustenia linkera je možné okrem obrazu spustiteľného súboru vytvoriť aj dátový súbor, ktorý obsahuje informácie, ktoré nie sú potrebné pri spustení programu, ale sú mimoriadne užitočné pri jeho ladení: názvy funkcií, globálne premenné, popis štruktúr. Symboly ladenia sú dostupné pre všetky spustiteľné súbory operačného systému. systémy Windows.
Riadenie vykonávania sa týka schopnosti prerušiť a obnoviť vykonávanie programového kódu po dosiahnutí daný príkaz v kóde programu. Ak sa programový kód vykoná v režime krok za krokom, prerušenie nastane pre každý symbol programovacieho jazyka alebo pri ukončení podprogramu. Pri voľnom vykonávaní dochádza k prerušeniu vo vopred určených častiach kódu - miestach, kde sú nastavené body prerušenia.
Pri prerušení kódu režimu jadra vzniká nasledujúca dilema. Ladiaci program používa používateľské rozhranie na interakciu s programátorom. Títo. aspoň viditeľná časť debuggeru beží v užívateľskom režime a na jeho zostavenie prirodzene používa aplikačné programovacie rozhranie (Windows API), ktoré sa zasa spolieha na moduly režimu jadra. Pozastavenie kódu v režime jadra teda môže viesť k zablokovaniu: systém prestane reagovať na požiadavky používateľov.
Na prístup k pamäti jadra musia byť časti ladiaceho programu spustené aj v režime jadra. To vedie k vzniku dvoch problémov naraz, ktoré sú zjavným dôsledkom organizácie pamäte v chránenom režime procesora.
Prvý problém sa týka prekladu adries virtuálnej pamäte. Ovládače neustále interagujú s aplikáciami v používateľskom režime prostredníctvom prístupu k svojej pamäti. Operačný systém Windows prekladá virtuálne adresy na fyzické adresy podľa konceptu kontextu vlákna. Kontext toku je štruktúra, ktorá odráža stav toku a zahŕňa najmä súbor registrov a niektoré ďalšie informácie. Keď sa kontrola prenesie do iného vlákna, dôjde k prepnutiu kontextu, v ktorom sa uložia informácie o jednom vlákne a obnovia sa informácie o inom. Keď sa kontext vlákna prepne na vlákno iného procesu, prepne sa aj adresár stránky slúžiaci na preklad virtuálnych adries na fyzické adresy.
Zvláštnosťou je, že pri odosielaní systémových volaní operačný systém Windows neprepína kontext. To umožňuje kódu v režime jadra používať virtuálne adresy v používateľskom režime.
Iná situácia je pri odosielaní prerušení alebo vykonávaní systémových vlákien. Prerušenie môže nastať kedykoľvek, takže nemôžete predpovedať, ktorý kontext vlákna sa použije. Systémové vlákna nepatria do žiadneho procesu a nemôžu prekladať virtuálne adresy v užívateľskom režime. Z toho vyplýva, že v týchto situáciách nie je možný prístup do pamäte užívateľského režimu.
Druhým problémom je prístup k premiestniteľnej pamäti. Väčšina informácií v pamäti je premiestniteľná a kedykoľvek ju možno presunúť z fyzickej pamäte do HDD do stránkovacieho súboru. Ak pristúpite na stránku, ktorá sa nenachádza vo fyzickej pamäti, procesor normálne vygeneruje prerušenie Page Fault, o ktoré sa postará správca pamäte, a v dôsledku toho bude stránka načítaná zo súboru stránky a načítaná do fyzickej pamäte.
Opísané správanie sa preruší, ak je kód ladiaceho programu nútený použiť vysoký stupeňúrovne požiadaviek na prerušenie (IRQL). Ak sa IRQL zhoduje alebo prekračuje IRQL správcu pamäte, tento nebude môcť načítať chýbajúcu stránku, pretože operačný systém zablokuje prerušenie Page Fault. To spôsobí zlyhanie operačného systému.
Ladenie sa zvyčajne delí na interaktívne a núdzové. Pri interaktívnom lokálnom ladení ladiaci program beží na rovnakom systéme ako objekt ladenia. Pri interaktívnom vzdialenom ladení ladiaci program a objekt ladenia bežia na rôznych systémoch. Pri ladení kódu jadra musí byť systém riadený od prvých fáz jeho zavedenia, keď sieť ešte nefunguje, preto sa na komunikáciu systémov používajú jednoduché sériové rozhrania ako COM, FireWire, USB. V poslednej dobe, vďaka trendom vo vývoji softvérovej virtualizácie na rôznych úrovniach abstrakcie, čoraz viac priťahujú virtuálne stroje. Hosťujúci OS funguje ako ladiaci OS, hosťovaný OS obsahuje používateľské rozhranie debuggera.
Núdzové ladenie teda nevyžaduje inštaláciu ladiaceho nástroja na testovacom stroji. Distribúcia operačného systému Windows obsahuje mechanizmy na implementáciu núdzového ladenia. Pred reštartom môže operačný systém uložiť informácie o svojom stave, ktoré môže vývojár analyzovať a zistiť príčinu. Tieto informácie uložené v súbore sa nazývajú výpis pamäte.
Základné nástroje na ladenie v režime jadra poskytuje výrobca operačného systému Windows ako súčasť freewarového balíka Debugging Tools for Windows. Nástroje zahŕňajú grafické a debuggery konzoly WinDbg, respektíve KD (ďalej len Windows Debugger). Práca týchto debuggerov sa spolieha na mechanizmy poskytnuté vývojármi operačného systému a zabudované do jeho jadra.
Hlavným režimom pre Windows Debugger je režim interpretovania príkazov. Vďaka modulárnej štruktúre spolu s dodanými vývojármi Príkazy systému Windows Debugger podporuje moduly tretích strán nazývané rozšírenia. V skutočnosti je väčšina vstavaných príkazov poskytovaná aj ako rozšírenia.
Windows Debugger je zameraný na vzdialené interaktívne a núdzové ladenie, pri použití sa odhalia všetky jeho schopnosti. Zároveň nie je podporované plnohodnotné lokálne interaktívne ladenie: debugger vám umožňuje zobraziť iba niektoré štruktúry jadra.
Existuje zásuvný modul Windows Debugger s názvom LiveKD, ktorý vytvoril Mark Russinovich a ktorý v istom zmysle implementuje lokálne interaktívne ladenie. LiveKD vytvára výpis pamäte produkčného systému za chodu a používa ho na ladenie.
Nástroje na ladenie pre Windows sa pravidelne aktualizujú, aby podporovali všetky moderné operačné systémy Windows.
Debugger jadra SoftICE od Compuware ako súčasť softvérového balíka DriverStudio je už tradične alternatívou k balíku Debugging Tools for Windows. Charakteristickou črtou SoftICE bola implementácia lokálneho interaktívneho ladenia na podporované hardvér... Debugger mal takmer úplnú kontrolu nad prevádzkou operačného systému.
K 3. aprílu 2006 bol predaj rodiny produktov DriverStudio prerušený z dôvodu „mnohých technických a obchodných problémov, ako aj všeobecných podmienok na trhu“. Najnovšia verzia Podporovaný operačný systém je Windows XP Service Pack 2. Balíky Service Pack zvyčajne nemenia rozhranie API operačného systému, ale čísla systémových hovorov a iné nezdokumentované informácie sa môžu zmeniť. Ladiaci program SoftICE sa spoliehal na pevne zakódované adresy interných dátových štruktúr. V dôsledku toho bola kompatibilita s vydaním balíka Service Pack 3 narušená. Je zrejmé, že novšie verzie operačného systému Windows tiež nie sú podporované.
Syser Kernel Debugger bol vytvorený malou čínskou spoločnosťou Sysersoft ako náhrada za debugger SoftICE. Prvá finálna verzia bola vydaná v roku 2007. Rovnako ako SoftICE, aj Syser Kernel Debugger je schopný interaktívneho ladenia na spustenom systéme. Podporované sú iba 32-bitové edície moderných verzií systému Windows.
Zapnuté tento moment Windows Debugger je primárny nástroj medzi vývojármi modulov jadra. Používa ho aj tím vývoja jadra Windowsu.
Pojem "ladenie jadra" sa týka skúmania vnútornej dátovej štruktúry jadra a/alebo postupného sledovania funkcií v jadre. Toto ladenie je veľmi užitočným spôsobom skúma interné zariadenie systému Windows, pretože vám umožňuje získať zobrazenie interného zariadenia systémové informácie ktorý nie je dostupný žiadnym iným spôsobom a poskytuje jasný pohľad na priebeh vykonávania kódu v jadre.
Pred zvážením rôzne cesty ladenie jadra, poďme preskúmať sadu súborov, ktoré budú potrebné na vykonanie akéhokoľvek druhu takéhoto ladenia.
Symboly ladenia jadra
Symbolové súbory obsahujú názvy funkcií a premenných a schému a formát dátových štruktúr. Generuje ich program linker a používajú ich ladiace programy na odkazovanie na tieto názvy a na ich zobrazenie počas relácie ladenia. Tieto informácie sa zvyčajne neukladajú v binárnom formáte, pretože nie sú potrebné pri vykonávaní kódu. To znamená, že bez neho sa binárny kód zmenšuje a zrýchľuje. To však tiež znamená, že pri ladení musíte poskytnúť debuggeru prístup k súborom symbolov priradeným binárnym súborom, na ktoré sa odkazuje počas relácie ladenia.
Použiť akýkoľvek nástroj na ladenie v režime jadra na vyšetrenie vnútorných štruktúr dátovej štruktúry jadro systému Windows(zoznam procesov, blokov vlákien, zoznam načítaných ovládačov, informácie o využití pamäte atď.) potrebujete správne súbory symbolov a aspoň súbor symbolov pre binárny obraz jadra, Ntoskrnl.exe. Súbory tabuľky symbolov sa musia zhodovať s verziou binárneho obrazu, z ktorého boli extrahované. Napríklad, ak je nastavený balík Windows Service Pack alebo nejakú opravu aktualizácie jadra, budete musieť získať vhodne aktualizované súbory symbolov.
Je ľahké sťahovať a inštalovať symboly pre rôzne verzie systému Windows, ale nie vždy je možné symboly aktualizovať pre opravy. Najľahší spôsob, ako sa dostať požadovanú verziu symboly na ladenie prístupom na vyhradený server Microsoft Symbol Server pomocou špeciálnej syntaxe pre cestu k symbolu špecifikovanú v ladiacom nástroji. Napríklad nasledujúca cesta k symbolu prinúti ladiaci program stiahnuť symboly z internetového servera symbolov a uložiť lokálnu kópiu do priečinka c: \ symbols: srv * c: \ symbols * http: //msdl.microsoft.com/download /symboly
Podrobné pokyny na používanie servera symbolov možno nájsť v súbore pomocníka pre ladiace nástroje alebo na internete na adrese http://msdn.microsoft.com/en-us/windows/hardware/gg462988.aspx.
Úvod
1. Typy ladiacich programov Windows
2. Debuggery užívateľského režimu
3. Debuggery v režime jadra
3.1 Debugger WDEB386
3.2 Debugger I386KD
3.3 Win DBG Debugger
3.4 SoftICE Debugger
4. Všeobecná otázka ladenia
5. Automatické spúšťanie aplikácií v debuggeri
5.1 Skratky prerušenia
Záver
Literatúra
Úvod
Najťažšou časťou procesu ladenia je naučiť sa, ako fungujú softvérové nástroje. Len ak pochopíte možnosti a obmedzenia nástrojov, môžete z nich vyťažiť viac a stráviť menej času ladením. Debuggery sú vo všeobecnosti mimoriadne užitočné, ale môžu viesť k pomerne jemným problémom, ktoré programátora zmiatnu. Táto kapitola vám ukáže, čo je debugger a ako fungujú rôzne debuggery v operačných systémoch Win32 (32-bitové operačné systémy Microsoft Windows).
V tomto prípade sa zameriame na tie špeciálne vlastnosti debuggerov vo všeobecnosti, ktoré sú povolené, keď je programový proces vykonávaný pod ich kontrolou. Tiež vysvetľuje, ako využiť niektoré vlastnosti 32-bitových operačných systémov Windows na uľahčenie ladenia. Predstavené budú dva vlastné debuggery, ktorých zdrojový kód nájdete na sprievodnom CD. Prvý z nich (MinDBG) má dostatok schopností na to, aby sa dal nazvať debuggerom. Druhý (WDBG) je príkladom ladiaceho nástroja Microsoft Windows, ktorý robí takmer všetko, čo skutočný systémový debugger, vrátane manipulácie s tabuľkami symbolov, manipulácie s bodmi prerušenia, generovania kódu disassemblera a koordinácie s grafickým používateľským rozhraním (GUI). V diskusii o WDBG vám ukážeme, ako fungujú body prerušenia a rozoberieme, čo sú rôzne súbory symbolov.
Predtým, ako prejdeme k hlavnému materiálu tejto kapitoly, definujeme dva štandardné pojmy, ktoré sa budú často používať v tejto knihe: hlavný (alebo základný) debugger a vedľajší debugger (debuggee). Zjednodušene povedané, hlavný debugger je proces, ktorý môže ladiť iný proces, zatiaľ čo vedľajší debugger je proces, ktorý beží pod hlavným ladiacim programom. V niektorých operačných systémoch sa hlavný debugger nazýva nadradený proces a podradený debugger sa nazýva dieťa.
Debugger (ladiaci program, anglický debugger z chyby) - počítačový program, určený na vyhľadávanie chýb v iných programoch, jadrách operačných systémov, SQL dotazoch a iných typoch kódu. Debugger vám umožňuje sledovať, monitorovať, nastavovať alebo meniť hodnoty premenných počas vykonávania kódu, nastavovať a odstraňovať body prerušenia alebo podmienky zastavenia atď.
Väčšina vývojárov viac pozná ladiace programy v užívateľskom režime. Nie je prekvapením, že tento ladiaci program je určený na ladenie aplikácií v užívateľskom režime. Hlavným príkladom ladiaceho nástroja v používateľskom režime je ladiaci nástroj Microsoft Visual C ++. Ladiace programy v režime jadra, ako naznačuje ich názov, sú ladiace programy, ktoré vám umožňujú ladiť jadro operačného systému. Používajú ich predovšetkým tí, ktorí píšu (a samozrejme ladia) ovládače zariadení.
2. Debuggery používateľského režimu
Ladiace programy v používateľskom režime sú navrhnuté tak, aby ladili akúkoľvek aplikáciu spustenú v používateľskom režime, vrátane akýchkoľvek programov s grafickým rozhraním, ako aj netypických aplikácií, ako sú služby Windows 2000. Vo všeobecnosti tieto typy ladiacich programov podporujú grafické používateľské rozhranie (GUI1) . .. Hlavnou črtou takýchto debuggerov je, že používajú rozhranie Win32 Debug Application Programming Interface (Debug API). Pretože operačný systém označí podriadený ladiaci program ako „bežiaci v špeciálnom režime“, môžete použiť rozhranie API IsDebuggerPresent na určenie, či váš proces beží pod ladiacim programom.
Pri odosielaní ladiaceho API Win32 platí konvencia, že akonáhle proces beží pod ladiacim API (a teda z neho robí podriadený proces), hlavný debugger sa nemôže od procesu odpojiť. Tento symbiotický vzťah znamená, že ak skončí hlavný debugger, skončí aj subdebugger. Hlavný debugger je obmedzený na ladenie iba podriadeného debuggera a akýchkoľvek procesov, ktoré vytvorí (ak hlavný debugger podporuje podradené procesy).
GUI - grafické užívateľské rozhranie. - Za.
Pre interpretované jazyky a run-time systémy, ktoré využívajú prístup virtuálneho stroja, samotné virtuálne stroje poskytujú kompletné ladiace prostredie a nepoužívajú Win32 debug API. Niektoré príklady týchto typov prostredí sú: virtuálne stroje Java (JVM) od spoločnosti Microsoft alebo Sun, skriptovacie prostredie pre webové aplikácie od spoločnosti Microsoft a interpret p-kódu v jazyku Microsoft Visual Basic.
operačný systém jadra ladiaceho nástroja
K ladeniu vo Visual Basicu sa dostaneme v kapitole 7, ale uvedomte si, že rozhranie Visual Basic p-code nie je zdokumentované. Nebudeme sa venovať Jave a rozhraniam na ladenie skriptov, tieto témy presahujú rámec tejto knihy. Ďalšie informácie o ladení a profilovaní Microsoft JVM nájdete v časti „Ladenie a profilovanie aplikácií Java“ na MSDN. Sada takýchto rozhraní je veľmi bohatá a pestrá a umožňuje úplne ovládať prevádzku JVM. Informácie o písaní ladiaceho programu skriptov nájdete v téme MSDN "Aktívne objekty rozhrania API na ladenie skriptov". Podobne ako JVM, aj objekty ladenia skriptov poskytujú bohaté rozhranie pre skriptovací prístup a dokumentáciu.
Prekvapivo veľký počet programov používa Win32 Debug API. Patria sem: ladiaci program Visual C++, ktorý je podrobne popísaný v kapitolách 5 a 6; Windows Debugger (WinDBG), o ktorom sa hovorí v ďalšej časti (o ladiacom nástroji v režime jadra); Softvér BoundsChecker od spoločnosti Compuware NuMega; Program platformy SDK HeapWalker; Platform SDK závisí od programu; Debuggery Borland Delphi a C++ Builder a NT Symbolic Debugger (NTSD). Som si istý, že ich je oveľa viac.
3. Debuggery v režime jadra
Debuggery v režime jadra sú umiestnené medzi CPU a operačným systémom. To znamená, že keď zastavíte ladiaci program v režime jadra, úplne sa zastaví aj operačný systém. Nie je ťažké si uvedomiť, že náhle zastavenie operačného systému je užitočné, keď pracujete s problémami s časovačom a načasovaním. Avšak s výnimkou jedného debuggera, o ktorom sa bude diskutovať nižšie (v časti SoftlCE Debugger tejto kapitoly), nemôžete ladiť kód používateľského režimu pomocou ladiacich programov v režime jadra.
Debuggerov v režime jadra nie je veľa. Niektoré z nich sú: Windows 80386 Debugger (WDEB386), Kernel Debugger (1386KD), WinDBG a SoftlCE. Každý z týchto debuggerov je stručne popísaný v nasledujúcich častiach.
3.1 Debugger WDEB386
WDEB386 je ladiaci program v režime jadra systému Windows 98 distribuovaný ako súčasť Platform SDK. Tento debugger je užitočný iba pre vývojárov, ktorí píšu virtuálne ovládače. Zariadenia so systémom Windows 98 (VxD). Ako väčšina ladiacich programov v režime jadra pre operačné systémy Windows, aj ladiaci program WDEB386 vyžaduje na spustenie dva počítače a kábel nulového modemu. Sú potrebné dva počítače, pretože časť ladiaceho programu, ktorá beží na cieľovom počítači, má obmedzený prístup k svojmu hardvéru, takže odosiela svoj výstup a prijíma príkazy z druhého počítača.
Ladiaci nástroj WDEB386 má zaujímavý príbeh... Začalo to ako interný nástroj na pozadí spoločnosti Microsoft v ére Windows 3.0. Bol náročný na používanie a chýbala mu dostatočná podpora pre ladenie zdrojového kódu a ďalšie pekné funkcie, ktorými nás kazili ladiace programy Visual C++ a Visual Basic.
Bodové príkazy sú najdôležitejšou funkciou WDEB386. Prerušenie INT 41 možno použiť na rozšírenie WDEB386 o pridávanie príkazov. Táto rozšíriteľnosť umožňuje autorom ovládačov VxD vytvárať vlastné ladiace príkazy, ktoré im poskytujú voľný prístup k informáciám vo ich virtuálnych zariadeniach. Debug Verzia systému Windows 98 podporuje mnoho príkazov DOT, ktoré vám umožňujú sledovať presný stav operačného systému v ktoromkoľvek bode procesu ladenia.
3.2 Ladiaci program I386KD
Windows 2000 sa líši od Windows 98 v tom, že skutočná časť ladiaceho nástroja v režime jadra je súčasťou NTOSKRNL. EXE - súbor hlavného jadra operačného systému Windows 2000. Tento debugger je dostupný vo voľnej (release) aj overenej (debug) konfigurácii operačného systému. Ak chcete povoliť ladenie v režime jadra, nastavte parameter zavádzača / DEBUG na hodnotu BOOT. INI a voliteľne možnosť zavádzača / DEBUGPORT, ak chcete nastaviť komunikačný port ladiaceho programu v režime jadra na inú ako predvolenú hodnotu (COM1). I386KD beží na vlastnom počítači a komunikuje s ním Stroj so systémom Windows 2000 cez kábel nulového modemu.
Debugger v režime jadra NTOSKRNL. EXE robí iba toľko, aby ovládal CPU, aby bolo možné odladiť operačný systém. Väčšina ladiacej práce – manipulácia so symbolmi, rozšírené body prerušenia a demontáž – sa vykonáva na strane 1386 kD. Súprava ovládačov zariadení Windows NT 4 (DDK) svojho času dokumentovala protokol používaný v kábloch nulového modemu. Microsoft to však už nezdokumentuje.
Sila 1386 kD je evidentná, keď sa pozriete na všetky príkazy, ktoré ponúka na prístup k internému Stav systému Windows 2000. Vedieť, ako fungujú ovládače zariadení v systéme Windows 2000, pomôže programátorovi sledovať výstup mnohých príkazov. Pri všetkej svojej sile sa i386KD takmer nikdy nepoužíva, pretože ide o konzolovú aplikáciu, ktorá je veľmi únavná na ladenie na úrovni zdroja.
3.3 Vyhrajte DBG Debugger
WinDBG je debugger, ktorý sa dodáva so súpravou Platform SDK. Môžete si ho stiahnuť aj z # "897008.files / image001.gif">
Obr 1. Výstup programu GFLAGS. exe
Výpis 4-1. Príklad zničenia haldy Windows 2000
void main (void)
HANDLE hHeap = HeapCreate (0, 128, 0);
// Alokácia pamäte pre 10 bajtový blok.
LPVOID pMem = HeapAlloc (hHeap, 0,10);
// Zápis 12 bajtov do 10 bajtového bloku (pretečenie haldy).
memset (pMem, OxAC,
// Pridelenie nového bloku 20 bajtov.
LPVOID pMem2 = HeapAlloc (hHeap, 0, 20);
// Zápis 1 bajtu do druhého bloku.
char * pUnder = (char *) ((DWORD) pMem2 - 1);
// Uvoľnite prvý blok. Táto výzva na HeapFree bude
// spúšťa bod prerušenia v kóde oblasti haldy ladenia
// operačný systém.
HeapFree (hHeap, 0, pMem);
// Uvoľnite druhý blok. Tento hovor nebude
// vydáva chybové hlásenia
HeapFree (hHeap, 0, pMem2);
// Uvoľnite fiktívny blok. Upozorňujeme, že tento hovor nebude
// tlač chybových hlásení
Ak začiarknete rovnaké políčka ako na obrázku 4.1 a zopakujete spustenie HEAPER. EXE, získate nasledujúci, podrobnejší výstup:
PAGEHEAP: proces 0x490 vytvoril haldu ladenia 00430000
(príznaky 0xl, 50, 25, 0, 0): proces 0x490 vytvorená halda ladenia 00CF0000
(príznaky Oxl, 50, 25, 0, - 0): proces 0x490 vytvorená ladiaca halda 01600000
(príznaky Oxl, 50, 25, 0, 0): Zistilo sa poškodenie výplne chvosta: pri veľkosti 0x01606FF0veľkosť 0x0000000Veľkosť 0x00000010 pri Ox01606FFA: Pokus o referenčný blok, ktorý nie je pridelený
Obsah zoznamu vysvetľuje názvy príznakov nastavených panelom Globálne príznaky.
Diskutuje o programe GFLAGS. EXE, chcem poukázať na jednu veľmi užitočnú možnosť - Show Loader Snaps. Ak začiarknete toto políčko a spustíte aplikáciu, uvidíte, čo sa nazýva snímka aplikácie, ktorá ukazuje, kde Windows 2000 načítava knižnice DLL a ako začína organizovať importy. Ak potrebujete presne vidieť, čo robí bootloader systému Windows 2000 pri načítavaní aplikácie (najmä v prípade, že sa v nej nájde problém), potom môže byť povolenie tejto možnosti veľmi užitočným opatrením. Ďalšie informácie o snímkach zavádzača nájdete v stĺpci Mata Pietreca „Under the Hood“ v časopise Microsoft Systems Journal zo septembra 1999.
5. Automatické spúšťanie aplikácií v debuggeri
Najťažšie laditeľné typy aplikácií sú tie, ktoré sú spustené iným procesom. Táto kategória je napadnutá služby Windows 2000 a out-of-process COM servery (COM out-of-process servers). V mnohých prípadoch môžete použiť DebugBreak API na prinútenie ladiaceho nástroja pripojiť sa k procesu. V dvoch prípadoch však táto funkcia nebude fungovať. Po prvé, niekedy to nefunguje so službami Windows 2000. Ak potrebujete ladiť spustenie služby, volanie DebugBreak pripojí debugger, ale v čase spustenia debuggeru sa môže stať, že službe vyprší časový limit a Windows 2000 ho zastaví. . Po druhé, DebugBreak nebude fungovať, keď potrebujete ladiť server COM mimo procesu. Ak zavoláte DebugBreak, obslužná rutina chýb COM zachytí výnimku bodu prerušenia a ukončí server COM. Našťastie vám Windows 2000 umožňuje určiť, že sa má aplikácia spustiť v debuggeri. Táto vlastnosť vám umožňuje spustiť ladenie hneď od prvého príkazu. Pred povolením tejto vlastnosti pre službu Windows 2000 sa však uistite, že je služba nakonfigurovaná na komunikáciu s pracovníkom. Windows stôl 2000.
Spustenie s vlastnosťou debugger je možné povoliť dvoma spôsobmi. Najjednoduchšie je spustiť utilitu GFLAGS. EXE a vyberte prepínač ObrázokSúbor možnosti(pozri obrázok 4.1). Po zadaní do editovateľného poľa I mágSúbornázov názvu binárneho súboru programu začiarknite políčko Debugger v skupine Obrázok Debuggermožnosti) a zadajte úplnú cestu k debuggeru do poľa úprav vedľa tohto začiarkavacieho políčka.
Zložitejší spôsob: musíte manuálne nastaviť potrebné parametre pre príslušné kľúče registra (pomocou editora RegEdit). V časti_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows NTX Aktuálna verzia \ Možnosti spúšťania obrázkovej dlaždice
vytvorte podkľúč s rovnakým názvom ako názov súboru vašej aplikácie. Napríklad, ak je názov aplikácie FOO. EXE, potom názov podkľúča databázy Registry je tiež FOO. EXE. V tejto podsekcii vytvorte nový reťazcový parameter s názvom Debugger. V dialógovom okne Zmeniť parameter reťazca zadajte pomocou klávesnice celý názov súboru (spolu s cestou k adresáru) ladiaceho nástroja podľa vášho výberu. Ak ste zadali GFLAGS. EXE a máte nainštalované nejaké globálne možnosti, budete si môcť všimnúť hodnotu malých písmen GiobaiFiag v kľúči vašej aplikácie.
Teraz, keď spustíte aplikáciu, automaticky sa načíta a spustí aj ladiaci program. možnosti príkazový riadok pre debugger možno zadať aj v parametri reťazca Debugger (za názvom programu ladiaceho nástroja). Napríklad, ak chcete použiť ladiaci program WinDBG a automaticky spustiť ladenie hneď po spustení WinDBG, musíte do dialógového okna na zmenu parametra reťazca ladiaceho programu zadať hodnotu d: \ platform sdk \ bin \ windbg. exe - g.
5.1 Skratky prerušenia
Niekedy sa musíte rýchlo dostať do debuggera. Ak ladíte konzolové aplikácie, potom stlačenia klávesov
Užitočnou funkciou Windows 2000 aj Windows NT 4 je možnosť kedykoľvek prepnúť na debugger aj v GUI aplikáciách. Pri spustení pod ladiacim programom stlačte kláves
V systéme Windows NT 4 klávesová skratka prerušenia
HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ WindowsNT \ CurrentVersion \ AeDebug
nastavte parameter userDebuggerHotKey na hodnotu keycode (VK_ *). Napríklad použiť kľúč
Záver
Preskúmali sme hlavné črty ladenia, jeho typy a typy, všeobecnú problematiku ladenia, ako aj chyby a spôsob ich odhaľovania.
Existujúce debuggery zohrávajú dôležitú úlohu pri vývoji softvéru pri hľadaní logických chýb, poskytujú širokú škálu nástrojov vrátane podpory zdrojového kódu, sledovania vykonávania aplikácií, modifikácie dynamickej pamäte atď. atď.
Literatúra
1 .. aspx? .Aspx? Id = 553022>
2. https: // ru. wikipedia.org/wiki/%D0%9E%D1%82%D0%BB%D0%B0%D0%B4%D1%87%D0%B8%D0%BA
Http: // bourabai. kz / alg / debug4. htm
4. Kostyukhin K. - LADENIE SYSTÉMOV V REÁLNOM ČASE. Prehľad
Táto séria článkov sa objavila z dvoch dôvodov. V prvom rade sa mi páči práca s projektom HackSysExtremeVulnerableDriver... Po druhé, mám veľa prianí na zdôraznenie tejto témy.
Všetok kód použitý pri písaní tejto série je v mojom úložisku.
V tejto sérii článkov sa pozrieme na písanie exploitov na úrovni jadra v systéme Windows. Je dôležité si uvedomiť, že sa budeme zaoberať známymi chybami zabezpečenia a nie je potrebné reverzné inžinierstvo (aspoň pre vodiča).
Po prečítaní všetkých článkov sa očakáva, že budete oboznámení so všetkými najbežnejšími triedami zraniteľností a metódami využívania, ako aj budete schopní preniesť exploity z architektúry x86 na architektúru x64 (ak je to možné) a zoznámite sa s nové metódy ochrany v systéme Windows 10.
Schéma ladenia jadra
Na rozdiel od ladenia na úrovni používateľa, keď je vykonávanie jednotlivého procesu pozastavené, na úrovni jadra je zapojený celý systém a túto metódu nemôžeme použiť. Preto potrebujete samostatný ladiaci stroj, ktorý dokáže komunikovať so systémom, kde sa ladí jadro, prezerať si štruktúru pamäte a jadra a zachytávať pády systému.
Dodatočný materiál na štúdium:
Využívanie zraniteľností jadra
Tento proces je oveľa zábavnejší ako využívanie používateľskej úrovne J.
Hlavným cieľom je dosiahnuť privilegované vykonávanie v kontexte jadra. A potom už všetko závisí od našej fantázie, od hostiny s domácim pivom až po zavedenie štátom podporovaného malvéru.
Vo všeobecnosti je našou úlohou získať shell so systémovými oprávneniami.
Témy pre túto sériu
- Časť 1: Nastavenie pracovného prostredia
- Konfigurácia troch virtuálnych strojov a systému, ktorý bude fungovať ako debugger.
- Konfigurácia WinDBG Debugger.
- Časť 2: Užitočné zaťaženia
- Preskúmanie najbežnejších užitočných zaťažení. Nasledujúce časti sa budú zaoberať konkrétnymi chybami zabezpečenia a podľa potreby poskytnú odkazy na tento článok.
- Ostatné diely.
- Zohľadnenie slabých miest.
Životný cyklus vývoja využívania na úrovni jadra
- Nájdenie zraniteľnosti... Tejto téme sa táto séria nebude venovať, keďže už presne vieme, kde sú diery.
- Zachytenie vlákna vykonávania... Niektoré zraniteľnosti zahŕňajú spustenie kódu, niektoré majú ďalšie požiadavky.
- Rozšírenie privilégií... Hlavným cieľom je získať shell so systémovými oprávneniami.
- Obnovenie toku vykonávania... Nezohľadnené výnimky na úrovni jadra spôsobujú zlyhanie systému. Ak sa nechystáte napísať exploit DoS, túto skutočnosť treba zvážiť.
Typy cieľových systémov
Budeme pracovať so zraniteľnosťami v nasledujúcich systémoch (konkrétna verzia nie je dôležitá):
- Win7 x86 VM
- Win7 x64 VM
- Win10 x64 VM
Začnime architektúrou x86 a potom prenesieme exploit do systému Win7 x64. Niektoré exploity neprebiehajú na strojoch Win10 kvôli novej ochrane. V tomto prípade buď zmeníme logiku exploitu, alebo použijeme úplne iný prístup.
Použitý softvér:
- Hypervisor (veľa možností).
- Windows 7 x86 VM
- Windows 7 x64 VM
- Windows 10 x64 VM
Nastavenie systémov na ladenie
Ladiace systémy, s ktorými budeme interagovať, sú navrhnuté tak, aby nahrali zraniteľný ovládač. Tieto počítače budú často padať, pretože väčšina výnimiek jadra prispieva k tomuto druhu správania. Je potrebné dostatočne alokovať Náhodný vstup do pamäťe pre tieto systémy.
Na každom počítači, ktorý sa bude ladiť, musíte urobiť nasledovné:
- V adresári VirtualKD spustite target \ vminstall.exe. Pribudne nový bootovací záznam a bude k dispozícii funkcia ladenia a automatické pripojenie k serveru VirtualKD nainštalovanému v systéme, ktorý funguje ako debugger.
V prípade Windows 10 VM je potrebné povoliť testovací režim podpisovania, ktorý umožňuje načítanie nepodpísaných vodičov do jadra.
Po spustení testovania bcdedit / set na príkaz a reštarte sa na pracovnej ploche zobrazí „Testovací režim“.
Stručný popis modulu HEVD
Procedúra DriverEntry je štartovacia procedúra pre každého vodiča:
NTSTATUS DriverEntry (IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath) (
UINT32 i = 0;
PDEVICE_OBJECT DeviceObject = NULL;
Stav NTSTATUS = STATUS_UNSUCCESSFUL;
UNICODE_STRING Názov zariadenia, DosDeviceName = (0);
UNREFERENCED_PARAMETER (Cesta registra);
PAGED_CODE ();
RtlInitUnicodeString (& DeviceName, L "\\ Device \\ HackSysExtremeVulnerableDriver");
RtlInitUnicodeString (& DosDeviceName, L "\\ DosDevices \\ HackSysExtremeVulnerableDriver");
// Vytvorte zariadenie
Stav = IoCreateDevice (DriverObject,
0,
& Názov zariadenia,
FILE_DEVICE_UNKNOWN,
FILE_DEVICE_SECURE_OPEN,
FALSE,
& DeviceObject);
- Tento postup obsahuje volanie funkcie IoCreateDevice obsahujúcej názov ovládača, ktorý budeme používať pri komunikácii.
- Požadované štruktúry a ukazovatele funkcií budú pridané do DriverObject.
- Pre nás je dôležitý funkčný ukazovateľ spojený s procedúrou DriverObject-> MajorFunction, ktorý je zodpovedný za obsluhu IOCTL (I/O Control; I/O control);
- V HEVD sa táto funkcia nazýva IrpDeviceIoCtlHandler, čo je veľký podmienený výraz s mnohými vetvami pre každý IOCTL. Každá zraniteľnosť má jedinečný IOCTL.
Príklad: HACKSYS_EVD_IOCTL_STACK_OVERFLOW je IOCTL, ktorý sa používa na aktiváciu zraniteľnosti pretečenia zásobníka.
Týmto sa končí prvá časť. V ďalšom článku si povieme niečo o užitočnom zaťažení. Momentálne je k dispozícii iba užitočné zaťaženie určené na kradnutie tokenov, ktoré budú použité v tretej časti.
P.S. Chápem, že existuje veľa jemností a problémov, s ktorými sa môžete stretnúť. Keďže sa tento cyklus zameriava na vývoj exploitov, všetky súvisiace problémy budete musieť vyriešiť sami. Môžete sa však opýtať na všetky otázky, ktoré sa objavia v komentároch.